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As I write this, we've just returned from a 
highly successful LISA '97 conference in 
San Diego (you shoulda been there!), so 
the juxtaposition of Hal Miller’s SAGE 
column and Elizabeth Zwicky’s always 
provocative views makes for particularly 
J topical reading. 


In fact, this is an opinionated issue: Lee Damon, across the way, thinks the Web is a fad; 
Tina Darmohray thinks pagers are good for you; Phil Cox isn’t so skeptical about 
Microsoft anymore; an anonymous contributor gives a backhanded compliment to NT; 
Rik Farrow keeps tearing down old fences; Dave Taylor writes poetry; and Peter Salus 
... well, you know Peter. 

Actually, we thrive on opinions, strongly expressed. This magazine exists in great part 
for you to let everyone know what you think about topics of interest to the community: 
use it. 

We hope you enjoyed the special issue on NT you received last month. We expect to 
produce special issues on particular topics from time to time. If you have any ideas 
about a topic you would like to see covered, let us know (and volunteer to be the guest 
editor!). 

On behalf of the USENIX Board, staff, and the ;login: editorial team, best wishes for the 
holiday season! 
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of Publication: Same. Publisher: USENIX Association, 2560 9th Street, Suite 215, Berkeley, CA 94710. Editor: Rob Kolstad. Managing 
Editor: Eileen Cohen, both located at office of publication. Owner: USENIX Association. The purpose, function, and nonprofit status 
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Extent and nature of circulation Average no. of copies of each issue in Actual no. of copies of single 

preceding 12 months issue published nearest to filing 


A. Total no. of copies 

9347 

10279 

B. Paid Circulation, Mail Subs. 

8577 

9112 

C. Total Paid circulation 

8577 

9112 

D. Free Distribution 

651 

1060 

E. Total Distribution 

9227 

10172 

F. Copies not distributed 

119 

107 

G. Total 

9347 

10279 

H % Paid circulation 

92% 

89% 


I certify that the statements made by me above are correct and complete. 
Ellie Young, Executive Director 


2 


Vol.22.No. 6 ;login 














imho:WWWhither(ing) 

Internet 



<nomad@castle.org> 


by Lee Damon 

Lee (a.k.a. nomad) has run 
castle.org since 1982. He is 
a senior systems administra¬ 
tor for a San Diego-based 
R&D company, and is never 
afraid to share his opinions 
about computing (and he 
doubts that his employer 
would wish to claim them). 


J 


Everyone’s using them now. They’re 
everywhere. Companies put them in their 
commercials. Kids compare them in class. 
Nerds (note the e) think they’re kOOl 
because they “own” one. It seems that 
URLs are taking over. 

It’s the fad of the decade: “My address is 
http://....” Web hosting companies are 
the Video stores of the 90s. Looking for a 
quick buck? Start an ISP, or better yet, 
just dedicate your company to Web host¬ 
ing. (Who needs to deal with all those 
pesky modems? There’s no money in 
that.) Anyone with a PC and some disk 
space can get into the act. Toss in an 
ISDN connection, or a frame relay line, 
and you’re in business. BSD/OS, FreeBSD, 
NetBSD, Linux all have tuning to help 
Web services run faster. Even NT is get¬ 
ting into the act, and some brave folks 
(fools?) make the effort with win95. 

Organizations like Prodigy, Netcom, 

AOL, Joe’s ISP, and CompuServe make 
fortunes off “the Web.” Free data they can 
sell to their customers! What better for¬ 
mula is there for getting rich? Install a 
link to the Internet at, oh, maybe 
$6,000/mo., and make $600,000/mo. 
Subtract a few dollars to pay for a small 
(overworked and understaffed) “cus¬ 
tomer support” group to answer ques¬ 
tions like “what’s a modem?” and the rest 


can go directly into your shareholders’ 
pockets. 

No real development costs, no paying 
nasty things like royalties to the people 
who invented the technology to make it 
possible. What venture-capitalist bliss. 

You see URLs at the end of TV commer¬ 
cials, hear them in radio spots, find them 
splattered all over billboards and maga¬ 
zine/newspaper adds. Any company that’s 
anyone has a Web page ... or two ... or 
three. Or a dozen. Want to sell your trin¬ 
ket? Looking for that perfect job appli¬ 
cant? Want to tell the world about your 
god(s)/goddess(es)? Plan to chase UFOs? 
Get a Web page and watch the hit rate 
climb. Not happy with your hit count? 

Put the word “sex” in your page, or pay 
Yahoo or AltaVista (or any number of 
other locators) and get your entry moved 
to the top of the list. 

Lots of people have them too. At times it 
seems like you can’t converse with anyone 
who doesn’t have a Web page. It’s self- 
publishing for the masses. Anyone with a 
message can publish on the Web. Mass 
communication at it’s proverbial best - 
or worst. Just how many shrines to Elvis 
does this world need? 

Everyone’s surfin’. People spend hours, 
even days, just surfin’ the Web. It has 
replaced TV in some households. The 
new refuge for the couch potato. Replace 
the remote with a mouse, and you have 
millions if not billions of things to stare 
at. Of course, the most popular pages are 
the ones that sell sex. At least those couch 
potatoes have healthy (?) libidos. 

(Though it gives one pause, I’ll not fol¬ 
low that line of thought any further.) 

Perhaps the saddest cut of all is that all 
these new, lost users keep thinking The 
Web is The Internet. 
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As with previous fads that made people 
rich, CB radio in the 70s, video stores, 
and object-oriented code in the 80s, this 
one will eventually saturate. People will 
tire of looking at the latest pictures of 
their neighbors newborn, or reading 
about Uncle Fred’s Caribbean vacation, 
or hearing Joe’s latest story about cat fun¬ 
gus. They’ll put the computer aside, 
switch off the modem, and move on to 
the next thing to grab the public’s fancy. 

Maybe the modem will be turned back 
on when Jimmy needs to do some 
research on his paper about dinosaurs, or 
Sally wants to work on her biology 
report, or dad wants to find a new recipe 
for grilled chicken, or mom wants to 
send email to her sister in Seattle. 
Generally the average household comput¬ 
er will once again be relegated to games, a 
bit of email, and the occasional balancing 
of the checkbook. 

A few years ago, a commentator on NPR 
compared the Internet to a small town 
with friendly neighbors where everyone 
knew everyone else and no one had to 
lock their doors. Then word got out 
about what a nice place it was to live, and 
all the tourists started showing up. Doors 
had to be locked, and all the friendly 


USENIX BOARD OF DIRECTORS 

Communicate directly with the USENIX Board of 
Directors by writing to: <board@usenix.org>. 

Andrew Hume <andrew@usenix.org> 

Vice President: 

Dan Geer <geer@usenix.org> 

Secretary: 

Lori Grob <grob@usenix.org> 

Eric Allman <allman@usenix.org> 


neighbors were smothered behind rows 
of ugly apartment blocks. 

Right now, this small town is suffering 
from its own success, building every¬ 
where, growing in leaps and bounds, 
without control or thought. Eventually, 
like No Name City in “Paint Your 
Wagon,” it’s going to collapse under its 
own weight. After the dust settles, it will 
once again be the domain of old timers 
and the few clued individuals who have 
discovered that the Internet is much 
more than just a Web and some Usenet 
posts. 

I can’t wait. 

In the meantime, unlike the AOLs of the 
world, I want to thank the people who 
made it possible; the early ARPAnet 
developers, the people who worked on IP 
to make it viable, the people who pushed 
the Internet to be strong and fast, the 
developers whose work is so fundamental 
to the Internet that we’ve all forgotten it’s 
there. All of us who make our livings 
from this industry, all of us who spend so 
much time at this as a hobby, anyone 
who’s ever sent email to Aunt Sally, or 
received a file from Cousin Jed; we all 
owe these people at least a “thank you.” 
Now if only they could collect royalties. 


Directors: 

Peter Honeyman <honey@usenix.org> 
Greg Rose <rose@usenix.org> 

Margo Seltzer <margo@usenix.org> 
Elizabeth Zwicky <zwicky@usenix.org> 

Executive Director: 

Ellie Young <ellie@usenix.org> 

CONFERENCES 

Judith F. DesHarnais 
Registration/Logistics 
Telephone: 714 588 8649 
FAX: 714 588 9706 
Email: <conference@usenix.org> 


"imho ’ ’ is an occasional 
column published in this space. 
If you feel strongly about a 
subject that would be of interest 
to our community, we will air 
it here. Please send your article 
to <login@usenix.org> 


USENIX Cancels New 
Network Technologies 
Symposium 

USENIX regrets that the New Network 
Technologies Symposium, which had 
been scheduled for March 2-3, 1998, has 
been cancelled because of an inadequate 
number of paper submissions. 


Erratum 

The previous issue of ;login: (special 
issue on Windows NT, November 1997) 
included incorrect deadlines in the 
Upcoming Events calendar for the 6th 
Annual Tcl/Tk conference. Please see this 
issue’s calendar and the Call for 
Participation for correct information. 


Zanna Knight 
Marketing 

Telephone: 510 528 8649 
FAX: 510 548 5738 
Email: <zanna@usenix.org> 

Cynthia Deno 

Vendor Exhibitions/Publicity 
Telephone: 408 335 9445 
FAX: 408 335 5327 
Email: <display@usenix.org> 

Daniel V. Klein 
Tutorials 

Telephone: 412 421 2332 
Email: <dvk@usenix.org> 
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Report from a Grace 
Hopper Celebrant 

by Nancy E. Reed 

An adjunct assistant professor at the Univ. of California, 
Davis, Nancy is involved in research in artificial intelli¬ 
gence and knowledge-based systems. Her recent work has 
helped develop diagnostic systems that were applied to 
computer hardware faults and congenital heart defects. 



[Editors Note: The Grace Hopper 
Celebratation of Women in Computing 
took place on September 19-21, 1997, in 
San Jose, California. USENIX was a 
Contributing Patron to the Conference, 
having donated $25,000 to supplement 
the scholarships and travel grants that the 
NSF provided for students wishing to 
attend the conference. Nancy Reed was 
one of 32 USENIX-sponsored scholar¬ 
ship recipients.] 

The Grace Hopper conference was an 
exceptional experience for me. I met a 
number of senior women in computer 
science, as well as a number of students 
and other recent graduates. The talks 
were all top-notch - timely, thoughtful, 
clear, concise, and they really conveyed a 
passion for work in the field. This was 
also true of the more inexperienced 
speakers I heard, including students. A 
great deal of preparation was evident for 
all the talks. (This has not been uniform¬ 
ly the case at any other conference Fve 


SAN JOSE, CALIFORNIA • SEPTEMBER 19-21, 1997 



been to!! Granted I haven’t been to hun¬ 
dreds, but I have been to at least six other 
conferences.) 


I would like to commend the organizers 
on the food - having meals prepaid and 
near the meeting rooms made it possible 
and convenient for me to meet many 
more people than I would have been able 
to otherwise. I will miss that at future 
conferences I attend. 

My sincere thanks to Scholarships Chair 
Tracy Camp and to USENIX for sponsor¬ 
ing my scholarship. I would not have 
been able to attend otherwise. 


With scheduled events from 8 or 8:30 
AM until 9 or 11 PM, the conference kept 
most of us extremely busy for over 12 
hours per day. I was exhausted as well as 
inspired by the talks and meetings I 
attended. I wish the conference could be 
held more frequently. I will definitely try 
to attend again in the future. 

Twenty Years Ago in 
;login: 



by Peter H. Salus 

Peter H. Salus is the author 
of A Quarter Century of UNIX 
(1994) and Casting the Net 
(1995). He has known Lou 
Katz for over 40 years. 


The November 1977 issue of ;login: was 
dominated by three things: the untimely 
death of Joe Ossanna, the publication of 
K&R; and Mel Ferentz’s move from 
Brooklyn College to Rockefeller 
University. 

Mel wrote: 
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Telephone: 510 528 8649 
Email: <office@usenix.org> 
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Eileen Cohen 
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USENIX SUPPORTING MEMBERS 
Adobe Systems, Inc. 

Advanced Resources 
ANDATAC0 

Apunix Computer Services 
Auspex Systems, Inc. 

Boeing Company 
Crosswind Technologies, Inc. 

Digital Equipment Corporation 


Earthlink Network, Inc. 

Invincible Technologies Corp. 
Lucent Technologies, Bell Labs 
Motorola Research & Development 
MTI Technology Corporation 
Nimrod AS 

O’Reilly & Associates 
Sun Microsystems, Inc. 

Tandem Computers, Inc. 

UUNET Technologies, Inc. 
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The UNIX community was saddened, 
and greatly diminished, by the recent 
death of Joseph F. Ossanna. As author 
of NROFF/TROFF, he spoke to us at 
the Urbana meeting and those of us 
who used early versions of the typeset¬ 
ter package will forever be in his debt 
for the generosity with which he gave 
of his time to explain the obvious to 
us. We join with his many friends at 
Bell Laboratories in expressing our 
sympathy to his family. 

Without Ossanna’s innovative programs, 
we might never have Kernighan and 
Cherrys eqn (1975) or Lesk’s tbl 
(1976), to say nothing of other important 
preprocessors. 

The November 1977 ;login: also proudly 
announced “On February 27, 1978, 
Prentice-Hall will publish The C 
Programming Language by Dennis Ritchie 
and Brian Kernighan ($9.95). Need we 
say more?” No, no more needed to be 
said; so Mel went on to apologize - for a 
failing that continued for nearly a decade 
more: 

We are still playing “catch up.” This 
newsletter is being prepared in early 
February 1978 and is the last issue of 
Volume 2. The next issue, nominally 
December-January, will be mailed 
before the end of February. 

There was also an apology that “no copies 
of the Toronto [tape] distribution have 
been mailed yet” and a remarkable 
notice: “This page appears twice in this 
issue.” The First was the “usual photo¬ 
typesetter output,” the second the “prod¬ 
uct of the Toronto typesetter simulator 
for the Versatec.” The Toronto simulator 
produced incorrect intercharacter spacing 
because it was set for Sovran and printing 
in Roman. 

Ferentz’s announced move to Rockefeller 
had an important implication for the 
group: “Rockefeller has agreed to act as 
fiscal agent for the Users’ Group.” 
Previously, the finances had been handled 
on a more informal basis. 


The first meeting of the UNIX Users 
Group had been held on May 15, 1974, in 
the Merritt Conference Room on the 
third floor of the College of Physicians 
and Surgeons. It was organized by Reidar 
Bornholt, Lou Katz, and Ferentz. About 
two dozen people from nearly a dozen 
institutions showed up. A year later (June 
18, 1975) “a meeting at City University of 
New York was attended by over 40 people 
from 20 institutions.” The first meeting 
outside of New York City was held at the 
Navy Postgraduate School, October 31, 

1975, organized by Belton Allen - no one 
divulged the significance of this being 
Halloween. 

On February 27-28, 1976, Berkeley got 
into the act: Bob Fabry organized the first 
two-day UNIX meeting. The next two 
conferences were at Harvard, “run” by 
Lew Law: April 1-2 and October 1-3, 

1976. Steve Holmgren hosted the next 
meeting at the University of Illinois, 
Urbana, May 19-21, 1977, memorable for 
his barbeque and beer bash. Tom Ferrin 
wrote me: 

During one night at the Urbana meet¬ 
ing all of the attendees (about 150) 
went over to Steve Holmgren’s house 
for a barbeque in the backyard. Seems 
to me a keg of beer was also there. This 
was before George Goble starting play¬ 
ing around with liquid oxygen for 
starting charcoal (see <http://ghg.ecn.pur- 
due.edu/> for details about that), but can 
you imagine inviting all the attendees 
of a USENIX meeting over to your 
house nowadays? You’d have to have a 
place the size of the Gates’ mansion. 

September 12-13, 1977 saw 100 attendees 
at SRI in Menlo Park, California, at a 
meeting organized by Oliver Whitby and 
John Bass. 

The young group was established and 
running: 1978 would move it further. 


1998 Election for 
Board of Directors 


by Ellie Young 

<ellie@usenix.org> 



The biennial election for officers and 
directors of the Association will be held 
in the Spring of 1998. A report from the 
Nominating Committee will be posted to 
comp.org.usenix and the USENIX Web site 
by December 15, 1997, and also pub¬ 
lished in the February issue of ;login:. 
Nominations from the membership are 
open until January 23, 1998. To nominate 
an individual, send a written statement of 
nomination signed by at least five (5) 
members in good standing (or five sepa¬ 
rate nominations), to the Executive 
Director at the Association office, to be 
received by noon, PST, January 23, 1998. 
Please include a Candidate’s Statement 
and photograph to be included in the 
ballots. 

Ballots will be sent to all paid-up mem¬ 
bers on or about February 18. Members 
will have until March 27 to return their 
ballots, in the envelopes provided, to the 
Association office. The results of the elec¬ 
tion will be announced in comp.org.usenix, 
the USENIX Web site, and in the June 
issue of ;login:. 

The Board is made up of eight directors, 
four of whom are “at large.” The others 
are the President, Vice President, 
Secretary, and Treasurer. The balloting is 
preferential; those candidates with the 
largest number of votes are elected. Ties 
in elections for Directors shall result in 
run-off elections, the results of which 
shall be determined by a majority of the 
votes cast. 

Newly elected directors will take office at 
the conclusion of the first regularly 
scheduled meeting following the election, 
or on July 1st, whichever comes earlier. 
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[Ablused Leashes 



<tmd@usenix.org> 


by Tina Darmohray 


Tina Darmohray, editor of 
SAGE News & Features, is a 
consultant in the area of 
Internet firewalls and net¬ 
work connections, and fre¬ 
quently gives tutorials on 
those subjects. She was a 
founding member of SAGE. 


I’ve had several interesting conversations 
lately that, surprisingly, revolved around 
pager technology. The first one took place 
at my investment club meeting between 
the members and our guest speaker, an 
investment fund manager. She pointed 
out that the cell phone market had scared 
investors away from pager companies, 
resulting in a deflated price of their 
stocks. We talked about whether we 
thought paging technology was dead. 
Several members of the club are also sys¬ 
tem administrators. They interjected that 
pagers are a different technology from 
cell phones and have their unique 
strengths. First, pagers allow you to 
screen your messages; you can return a 
page if you choose to. But once you’ve 
answered a cell phone, you’re stuck. Also, 
pagers can send you time-critical infor¬ 
mation, whether or not you answer. For 
example, computers can page people 
when something is happening: “tempera¬ 
ture has reached 92 degrees in machine 
room E.” A wife can tell her husband that 
plans have changed: “meet us at Ital- 
ianos’; the kids refused to step foot in the 
Indian place.” Neither of these messages 
requires a person to answer the phone, 
but the information still reached the 
recipient in realtime. 

I remember when pagers first came on 
the scene at my office. Some folks wore 
them as a kind of “badge of courage”; 
others made the comment, “I don’t do 
pagers.” Both these groups were address¬ 
ing the concern that wearing a pager 


often brings: it can turn your day job into 
a 7x24 operation, with you covering all of 
those hours! Of course, no one wants 
that kind of scenario. I know, as a man¬ 
ager, I sought out information from other 
system administration managers on how 
they compensated an employee who was 
“on call” via a pager. I found many inter¬ 
esting approaches. The most common 
went something like this: “you will be 
compensated [overtime pay] for sched¬ 
uled hours that you are on call. On call 
means that you are within an hour travel¬ 
ing time of the site and provide 30 
minute telephone response time.” Note 
that everything is spelled out, including 
what hours you’re on call, which makes 
everyone a lot happier about wearing 
pagers. This kind of use of pagers helps 
groups provide off-hours coverage in an 
organized and predictable way; it can 
benefit both the sysadmins and their 
users. 

Another way that my group used pagers 
to increase our overall sysadmin “cover¬ 
age” was to enlist them in our plight to 
justify hiring new system administrators. 
Hiring justification usually involved the 
system administrator manager (me) 
putting together some report on how 
many tasks are getting done vs. how 
many tasks are being left undone and 
how the latter queue was increasing over 
time. I used to prepare the report and 
then, inevitably, was asked to present it to 
the powers that be. During those meet¬ 
ings, my fellow sysadmins would take 
turns paging the daylights out of me so 
that the meeting attendees would see, 
firsthand, that the system administrators 
were so busy that our pagers were getting 
hit every four minutes. I suppose the 
danger in this approach is that unsympa¬ 
thetic managers could choose to stock 
up on pager batteries, rather than 
employees. 

Of course, I’ve experienced paging tech¬ 
nology at a personal level as well. My 
husband is tied to a pager. When it was 
upgraded to an alpha-numeric variety 
and tied to his email, I found it to be a 


tremendous benefit. This way I can keep 
a running conversation going with him 
while he works (and he can’t really fight 
back). I sometimes take devious pleasure 
in letting him know the goings-on back 
on the home front. Recently, I paged him 
with the news that the children had 
found a dead rat under the house and 
that it would be waiting for him upon his 
return. “Can’t wait for you to get home, 
dear.” Before you all side with my poor 
husband, I’ll point out that his pager, set 
to vibrate, deftly switches to audible 
tones to warn of a low battery; it’s been 
my experience that that happens around 
2:00 am. 

It’s those “inopportune” pages that cause 
all of us to question who really benefits 
from pagers, the person wearing one, or 
the person dialing one. We often hear the 
analogy of being put on a leash by getting 
a pager. My husband contends that a 
pager, used correctly, can work to the 
benefit of the wearer. He points out that, 
as a manager, he can be available for 
questions without having to be onsite all 
the time, especially during times his 
group is working around the clock to get 
a product out. Sure, he’s tied to a pager, 
but the alternative is to be tied to the 
office. I guess that makes sense, but it’s 
harder to swallow when he has to leave in 
the middle of the school play. 

Yesterday I called an old school buddy of 
mine, now an attorney. We had been 
playing telephone tag for over a week. He 
finally left me instructions to have his 
secretary page him if he was not at his 
desk when I called, which I did. I started 
the conversation by apologizing for hav¬ 
ing him paged, because the call was cer¬ 
tainly not urgent. He responded that it 
really was the way he preferred to do 
business because it made sense. He said, 
“Hey look, when I get a page, if I’m busy, 

I don’t pick up the phone. I use my pager 
that way. I think people who don’t use 
their pagers as a leash aren’t using the 
technology to their benefit. So I wasn’t 
busy, and I’m glad you had me paged so 
we can finally talk.” 


December 1997 ;login: 


7 







Of course, I didn’t call to talk about 
pagers, but once he made that comment, 

I had to ask him what he meant by it. He 
came back with a story about an 
unhappy colleague of his who had just 
spent the entire weekend working on a 
crunch project for a client who was still 
furious with her, even though she com¬ 
pleted the project by Monday. My friend 
asserted that her mistake was she had 
failed to take advantage of pager technol¬ 
ogy. Apparently, her schedule required 
that she travel over the weekend, but she 
had taken her laptop computer so she 
could work on the plane, etc. However, 
she didn’t know that while she was dili¬ 
gently working, her client was leaving 
increasingly frantic voice mail messages 
back at the office. My friend suggested 
that if she had just had a pager, she could 
have easily known that her top-priority 
client was trying to reach her and given 
him a quick “warm fuzzy” call. That way 
she could have delivered the goods and 
kept the client happy at the same time. 
The analogy that my friend used for 
pagers was that they are like a leash for a 
dog. “Without a leash, the dog stays at the 
office; with one, the dog still gets the 
work done, but now gets to go out for a 
walk.” 

We’ve all seen the commercials of the 
employee making the business call from 
the golf course. I think my friend is right. 


Why I Am Not A 
Professional System 
Administrator 


By Elizabeth 
Zwicky 

Elizabeth is technical lead of 
the European Desktop Project 
at Silicon Graphics. She was 
a founding member of SAGE 
and is currently on the 
USENIX Board of Directors. 

<zwicky@pterodactyl.neu.sgi.com> / 

The first thing we need to get straight is 
that I am not, in fact, a professional sys¬ 
tem administrator. You might be con¬ 
fused on this point; I was, until some 
time last month. After all, I’m clearly not 
an amateur system administrator - I 
don’t think I’ve ever administered a sys¬ 
tem for the sheer joy of it. I also believe 
that my work as a system administrator is 
of high quality and displays those semi¬ 
tangible qualities known collectively as 
“professionalism” (as in, “Well, painting 
the tail-light red with nail polish does 
meet the legal requirements, but it’s 
hardly the professional way to repair it.”) 

But over the years in working with SAGE, 
it’s been clear that there’s a big compre¬ 
hension gulf between me and many of 



my colleagues, often despite mutual 
respect that verges on hero-worship. 

Early on in SAGE prehistory, it became 
clear that you could divide the board very 
neatly into people who were interested in 
professional issues and people who 
wanted to do random things to make life 
better for system administrators. On one 
side, for instance, we had the people 
arguing for a code of ethics and certifica¬ 
tion; on the other, we had the people 
arguing for local groups and Web sites 
with FAQs on them. Each side thought 
the other side’s most important issues 
were kind of cute, but not really impor¬ 
tant. We made progress mostly because 
we found occasional areas of overlap and 
because the two agendas are parallel. If 
you have enough people, you can pursue 
them both without major problems. 

However, we occasionally end up in 
actual conflict. The code of ethics, for 
instance, is an obvious benefit for some 
people, whereas I find it at best a harm¬ 
less idiosyncrasy and at worst an intolera¬ 
ble attempt to control matters of 
conscience. That’s not actually what I 
want to debate right now, but it is the 
deciding issue that pushed me back into 
discussing these matters with people. 

And it was in the middle of that discus¬ 
sion that somebody made a key observa¬ 
tion. It’s these issues, he said, that divide 
professional system administrators from 


SAGE, the System Administrators Guild, is a 
Special Technical Group within USENIX. It is 
organized to advance the status of computer 
system administration as a profession, 
establish standards of professional excellence 
and recognize those who attain them, develop 
guidelines for improving the technical and 
managerial capabilities of members of the 
profession, and promote activities that advance 
the state of the art or the community. 

To achieve its mission SAGE may: 

Sponsor technical conferences and workshops; 

Publish a newsletter, and/or professional 
short topics series; 


Develop a process for the certification of 
professional system administrators; 

Recognize system administrators who are 
outstanding or are otherwise deserving of 
recognition for service to the professional 
community; 

Speak for the concerns of members to the 
media and make public statements on issues 
related to system administration; 

Promote and support the creation and activities 
of regional or local professional system 
administrators. 


SAGE STG EXECUTIVE COMMITTEE 

President: 

Hal Miller <halm@usenix.org> 

Secretary: 

Tim Gassaway <gassaway@usenix.org> 

Treasurer: 

Barb Dijker <barb@usenix.org> 

Members: 

Helen Harrison <helen@usenix.org> 

Amy Kreiling <amy@usenix.org> 

Kim Trudel <kim@mit.edu> 

Pat Wilson <paw@usenix.org> 


Develop curriculum recommendations and 
support education endeavors; 
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people who’re just in it for the money - 
not that he’d accuse me of just being in it 
for the money. I hate to shatter anybody’s 
illusions, but I’m in it for the money. I 
didn’t know there was anything wrong 
with that. As I said, I’ve never in my life 
administered a system for the sheer joy of 
it, and I am roughly as likely to start as I 
am likely to start playing football for 
amusement. (Although I must admit my 
motivations are slightly mixed, 1 am 
clearly not in it for the money as much as 
some people, having reduced a recruiter 
to a state of near-speechlessness in which 
he could only gasp, “You’re not willing to 
be snowed on for a quarter million dol¬ 
lars a year?” Apparently, I was supposed 
to salivate at the sound of the cash regis¬ 
ter bell.) 

Now, I think it’s unethical to be a minis¬ 
ter just for the money, or even a doctor. I 
also think it’s unethical to do a bad job at 
something in order to make a fast buck. I 
think it’s unhealthy to care more about 
money than anything else about your job. 
But I see nothing wrong with picking any 
branch of working with computers as an 
honest way of making a living, doing a 
good job of it, and going home at night 
with no particular further commitment. 

Partly this is because I grew up in the 
academic world, where jobs you might 
admit to having are divided roughly into 
three camps. There is real work, which 


involves adding to the world’s supply of 
knowledge. There is honest work, which 
is, well, most of the other ways of making 
enough money to keep body and soul 
together. And then there are a few call¬ 
ings, like ministries and the arts, which 
you do out of sheer love for it. Being a 
system administrator, like being a lawyer, 
secretary, accountant, truck driver, engi¬ 
neer, or waitress, is honest work. The dis¬ 
tinctions between these jobs have to do 
with things like how much they pay, how 
pleasant they are, and what core compe¬ 
tencies they demand. You can lump them 
together in lots of ways; for instance, you 
can make a distinction between blue-col¬ 
lar and white-collar jobs, jobs that 
require uniforms and ones that don’t, 
and sedentary and active jobs. 

Apparently, many other people can divide 
these things into professions and jobs, 
and most of these people who are system 
administrators believe that system 
administration really is a profession and 
it is important to convince everybody else 
of it. I am deeply unclear on this concept. 
It is clear to me that “profession” is a cul¬ 
tural construct, which is high status. 
Something that is “unprofessional” is bad. 
Being a professional is good. My grand¬ 
mother thinks I am a professional 
because the TV ads for trade schools talk 
about “highly paid computer profession¬ 
als.” Besides, I have a college degree. My 


mother-in-law doesn’t think I’m a profes¬ 
sional, because I have only a bachelor’s 
degree and because in her mind any job 
you can wear shorts and sandals to is not 
a profession. 


As far as I can tell, that about sums up 
the state of things when it comes to 
defining a profession. For most people in 
the world, system administration already 
is one: you have to learn a lot of stuff, 
and you get paid (relatively speaking) lots 
of money. For the rest of the world, the 
key indicator for whether or not some¬ 
thing is a profession is how much you 
have to suffer to enter the field, and any¬ 
thing that doesn’t involve a long and 
expensive degree process is just not worth 
considering. The difficulty of convincing 
people that what you do is a profession 
varies according to the social status of 
what they do, along with its mystique. 

Try convincing an engineer - not a Certi¬ 
fied Netware Engineer but a genuine we- 
build-dams-that-don’t-fall-down (often) 
civil engineer, for instance - that system 
administration is a profession in the 
same sense that engineering is. It isn’t 
going to work, but when you get 
depressed trying, you can always amuse 
yourself by trying the same argument 
only using any nonmathematical profes¬ 
sion (dentistry, say, or being a professor 
of Romance languages). Or you could try 
to convince a doctor that civil engineer- 
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ing is a profession in the same sense that 
medicine is. As a party game, this is kind 
of amusing, but I have better things to do 
in real life. 

So, it turns out, I am not a professional 
system administrator. I am still trying to 
decide what I am - a practical system 
administrator, perhaps. 

This opens up the question of what I am 
doing involved with SAGE, which is “ded¬ 
icated to the advancement and recogni¬ 
tion of system administration as a 
profession.” (It seemed to me that I had 
seen USENIX describe itself as an associ¬ 
ation for advanced computing profes¬ 
sionals, but we appear to currently settle 
for “USENIX is the advanced computing 
association,” without specifying who or 
what associates.) It certainly seems to call 
into question how I managed to get an 
award for advancing the profession. 

And the answer here may be a certain 
amount of confusion on both sides. What 
I consider to be nice, straightforward 
ways of making system administrators’ 
lives better often strike other people as 
somehow involving “system administra¬ 
tion as a profession.” For instance, I’m 
known to believe that system administra¬ 
tion makes a perfectly reasonable career, 
not just somewhere you go while you’re 
waiting to grow up to be a programmer. I 
publish about “professional” (i.e., non¬ 
technical) issues. (The idea that a squeaky 
octopus is more of a professional issue 
than a sendmail. cf file strikes me as a 
trifle bizarre, but if you divide the world 
into “technical” and “professional,” that’s 
what you get. This may help explain 
some of my confusion about the entire 
question.) 

I am interested in advancing system 
administration. I consider the question of 
whether or not it’s a profession somewhat 
lower in interest than the question of 
how many angels can dance on the head 
of a pin, which has a long and honorable 
history. I think it’s naive to believe that it 
would reduce the political battles, or 
make people more willing to hire the sys- 
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tern administrators that they need, if sys¬ 
tem administration were widely consid¬ 
ered a profession. (Health maintenance 
organizations seem to have no problem 
treating doctors with disrespect and 
understaffing.) I think it’s downright 
offensive to believe that it’s necessary to 
be a professional to deserve respect. 

I am therefore going to wander off in my 
unprofessional way, doing what seems to 
be the right thing; I invite everybody else 
to do the same, even if that’s making sys¬ 
tem administration a profession, as long 
as they promise not to assume that being 
a professional is an inherent good that 
should be obvious to everyone. 

C President's Column ) 

by Hal Miller 

Hal Miller is president of the 
SAGE STG Executive Commit¬ 
tee. 


J 

This article presents my understanding of 
the state of, and my proposed direction 
for, SAGE education and certification 
efforts. It may be the basis for communi¬ 
tywide discussion and implementation of 
these programs. Questions and com¬ 
ments may be submitted to this forum or 
directly to me <halm@usenix.org>. 

One of the charter goals of SAGE has 
been to address the educational require¬ 
ments of its membership and of system 
administrators as a group. The details of 
our profession have been thus far learned 
almost exclusively on the job, generally in 
a rather haphazard manner. There is no 
widely accepted method of determining 
what an individual knows. We as a guild 
are united (as strongly as we are ever 
united) behind the idea of promoting a 
consistent education program to ensure a 
minimum level of qualification. 



<halm@usenix.org> 


A second, less clearly defined goal, has 
been to create an industrywide recogni¬ 
tion program that provides employers an 
indicator of the training levels achieved 
by current or prospective employees. 
What that recognition ought to be and 
how it might be effected have been a 
murky swamp, with no consensus or 
agreement. 

Both these goals have inspired conversa¬ 
tion and debate, sometimes intense. 
Neither has resulted in implementable 
plans or programs to date, partly because 
they are “tough problems” that take a 
lot of work to solve and partly because 
the organization has been busy with for¬ 
mation issues. 

SAGE is now in a position to address 
these goals. Given the apparent industry 
demand, and the number of vendor-spe¬ 
cific education and certification pro¬ 
grams now available, this has become 
time-critical and requires immediate 
application of SAGE organizational and 
individual resources. 

I define two types of education for the 
purposes of this article: formal and on- 
the-job. I also define two types of certifi¬ 
cation: topic and comprehensive. 

Formal education is generally carried out 
in the classroom or by correspondence. It 
follows an “accepted” or “standard” cur¬ 
riculum or course of study and employs 
qualified instructors who present infor¬ 
mation and monitor progress. It covers 
theory, background material, and meth¬ 
ods of application to practice. On-the-job 
training (OJT), or informal education is 
usually carried out in the workplace, 
either managed by the student directly or 
mentored by a more seasoned profes¬ 
sional. It emphasizes the practical. OJT 
might be accomplished in an apprentice¬ 
ship program, correspondence course, or 
nonstructured individual training. 

Comprehensive certification is what most 
people think of when they hear the term 
“certification.” It is common in many 
professions and demonstrated by exam- 
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Figure 1: Professional development pyramid 



pies such as a license to practice medi¬ 
cine, dentistry, or law, a P.E., or a jour¬ 
neyman's certificate for electricians. 

These are widely accepted, and they cover 
large numbers of topics. Topic certifica¬ 
tion is limited in scope to one or two 
topics and is acceptable only to those 
organizations for which the specific top¬ 
ics are applicable. Examples of topic cer¬ 
tifications are those given to automobile 
mechanics for brakes, emission control, 
or air conditioning service. 

Vendor-specific system administration 
recognition methods, such as the Certi¬ 
fied Network Engineer from Novell, or 
the new Sun Microsystems certificates, 
are a new and relatively limited form of 
“certification.” They are not truly “topic,” 
because they cover multiple topics. They 
are not “comprehensive,” because they 
cover things from only one viewpoint 
and include only topics relevant to that 
vendor’s hardware or software. This is a 
trend that could result in large numbers 
of similar programs, each limited to a 
given vendor, none of which would be 
.really applicable in the standard hetero¬ 
geneous site, but would be sufficient to 
convince some companies to require one 
or more from their sysadmin candidates. 

A number of building blocks must be 
engineered and constructed in the devel¬ 
opment of education and certification 
programs for system administrators. 
There is a natural pyramid resulting, 
built of a series of interdependent project 
areas, each of which has its own reason to 
exist (see Figure 1). Blocks of the higher 
levels require those of the lower levels as 
prerequisites. At the base of this pyramid 
is the description of our job. Next comes 
a definition of ethical considerations that 
shows something about who we are. With 
these, we can develop an acceptable defi¬ 
nition of a system administrator. We then 
tackle the training for the job as de¬ 
scribed, for both on-the-job and class¬ 
room education. Once we have all these 
blocks, we are ready to debate the merits 
of certification, then, if we are going to 
proceed, to define programs for certifying 
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sysadmins, first, on a topic-by-topic basis, 
then in the comprehensive arena. 

We already have the foundation block in 
the jobs descriptions booklet. This has 
proven immensely successful in its own 
right; plus it gives us the starting point 
for this pyramid. 

There is now a code of ethics document. 
Debate on what it means has not sub¬ 
sided, nor will it stop for some time to 
come. We do, though, have a base from 
which to proceed. 

Many attempts have been made to cap¬ 
ture in a sentence or two the definition of 
a system administrator. One of those 
attempts may eventually fit our need, but 
thus far the “real” definition has eluded 
us. Our daily jobs encompass many dis¬ 
parate areas. 

The best available definition of a system 
administrator, so far, is one who, as a sig¬ 
nificant part of his or her job function, 
manages the operational and data 
integrity of networked computing sys¬ 
tems for use by others. 

We “know,” as a community, what sort of 
OJT is required to train a working sysad¬ 
min. Documenting this and drafting a 
program to standardize, publish, and 
monitor OJT are currently under way. A 
Short Topics booklet will be out soon 
that will also define a core formal cur¬ 
riculum. A number of universities are 
already teaching a course or series of 
courses, all of which are acting as proving 
groups (as well as supplying new sysad¬ 
mins). 

The Executive Committee is looking at a 
proposal by Pat Wilson (using the work¬ 
ing title of “merit badges”) that provides 
guidelines for teaching/learning pieces of 
the job independendy of other pieces. 
Such a proposed system now gives us a 
few task area descriptions/checklists, and 
others will trickle in as they become 
available. These tasks both stand on their 
own to teach individual subjects, and 
begin to aggregate to form a larger edu¬ 
cation program. The system allows us to 


field-test and apply the lessons learned. 
This proposal lends itself well to the 
“topic certification” role, providing the 
framework for a recognition program 
without the attendant legal and political 
baggage. This recognition/certification 
by-product allows us to develop and 
field-test ideas that may eventually make 
their way into a “real” comprehensive cer¬ 
tification process. 

With a formal curriculum established, 
the OJT commonplace (thus covering 
both parts of the education dichotomy), 
and clarity with regard to the job defini¬ 
tion, the time is right to begin the review 
of what certification means, what it 
doesn’t mean, and implementation 
options. We will soon have practical 
experience, and the benefit of working 
programs of education and “minicertifi¬ 
cation.” 

System administration is not a statutorily 
regulated profession, as are the medical 
and legal fields. Those require certifica¬ 
tion in order to practice. They require 
adherence (including “word of honor”) 
to a code of ethics. What we are building 
is different. No sysadmin will be required 
to do these things in order to perform the 
duties, use the title, or even become a 
member of SAGE. The purpose of these 
programs is to advance ourselves as indi¬ 
viduals and as a group, not to regulate 
the membership. 

We are at this point pursuing further 
clarification of the code of ethics and the 
codification of the merit badge proposal 
into a workable program. The next step is 
to lay out certification definitions, the 
pro and con arguments, and options. 

One of those options appears to be to set 
up a comprehensive plan based on vari¬ 
ous combinations of topic certifications. 
Results of that definition exercise will 
find their way to the membership soon. 

We are dangerously close to being “too 
late” as the number of other bodies and 
vendors offering both education and cer¬ 
tification increases. We must not sit idly 
by, but continue to press forward. 
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by Phil Cox 

Phil is a member of the Com¬ 
puter Incident Advisory 
Capability (CIAC) for the 
Department of Energy. He 
also consults and writes on 
issues bridging the gap 
between UNIX and Windows 
NT. 


( Windows NT 5.0 : Integration Friendly? ) 

I am on the plane home from the Microsoft Professional Developers Conference 
and I am amazed at the effectiveness of Microsoft. Although I am a longtime 
UNIX supporter, I have to admit that this conference has made me much less 
skeptical about Microsoft’s ability to embrace good technology solutions. I left 
feeling that the road to decent integration between NT and UNIX is a feasible 
thing, and with the next release of NT (version 5.0), that process has a good 
start. 


Although NT 4.0 has good built-in security features, the integration with UNIX-based 
systems has left a lot to be desired, especially in the area of secure communications. 
Windows NT 5.0 starts to bridge the gap in this area. With the incorporation of Active 
Directory (AD) - a Lightweight Directory Access Protocol (LDAP) compatible directory 
service - and Kerberos, a foundation for interoperability is being laid. Here is an 
overview of these two features and their use in intergrating NT and UNIX. 


Active Directory: Microsoft’s Version of NIS+ 

Basics 

For anyone familiar with Sun’s NIS+, the Active Directory will seem very familiar. 

The parallels between NIS and NT 4.0 domains and NIS+ and Active Directory are 
remarkable. 

The Windows NT Active Directory provides the store for all NT domain security policy 
and account information. It also provides replication and availability of account infor¬ 
mation to multiple Domain Controllers [1]. The AD supports the LDAP that enables 
you to link the Windows NT directory with other LDAP/X500 directories. The AD also 
supports fine-grain access control. With this granularity, access rights can be granted 
down to individual properties on user objects (NIS+ {row,entry}). This enables a spe¬ 
cific individual or group to have the right to reset passwords, but not to modify other 
account information. This new ability is unlike NT 4.0, which required Domain Admin 
permissions (i.e., total control) to modify any portion of the domain information. 

Another difference in NT 5.0 is that all Domain Controllers are considered equal, so 
updates made on any one of them modify the Active Directory. In NT 4.0, modifica¬ 
tions were made only to the files on the Primary Domain Controller (PDC), then prop¬ 
agated. The NT 5.0 structure is called “multiple master.” Like NIS+, you have a PDC 
(master in NIS+) and as many replicas (formerly Backup Domain Controllers) as 
needed. Because all are considered equal, updates made on one are made and synchro¬ 
nized to all others automatically (just like NIS+). 

Structure Changes 

The structure of the directory has changed as well. Like the transition from NIS, with its 
flat namespace, to NIS+ and its hierarchical namespace, the Windows NT domain 
model changed. NT 4.0 used a flat namespace and one-way trust relationships; NT 5.0 
Active Directory uses a multilevel hierarchy tree of domains. Management of trust rela¬ 
tionships between domains in the AD is simplified through treewide transitive trust 
throughout the domain tree. 
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Jsage 

Jnlike NT 4.0, which uses account information maintained in a secure portion of the 
egistry on the Domain Controller, the NT 5.0 distributed security services use the 
\ctive Directory as the repository for account information. The AD improves perfor- 
nance, scalability, and administration. The trust relationships are also much easier to 
nanage. The NT 4.0 model of using domain trust and pass-through authentication was 
nuch more cumbersome than the transitive trust and Kerberos delegation that comes 
vith NT 5.0. 

Security 

\D security is directly dependent upon physical security and the underlying NT 5.0 OS 
security, primarily the security features of Access Controls and NTFS. 

Kerberos: A Move Toward Integration 

Windows NT 5.0 has added support for more security protocols. Currently, NT 4.0 and 
earlier versions utilize the Windows NT LAN Manager (NTLM) protocol. This protocol 
is limited to Microsoft and does not integrate in heterogeneous environments. 

Microsoft understood this and decided to support a protocol that is truly platform 
independent: Kerberos. 

Kerberos Version 5 (RFC 1510) will replace NTLM as the primary security protocol for 
access to resources within or across Windows NT 5.0 domains. Kerberos is a standard 
that will provide for network authentication of heterogeneous machines. Some of the 
benefits of Kerberos are mutual authentication of both client and server, reduced load 
on the server during logon, and support for authorization delegation. Although Ker¬ 
beros V5 will be the default authentication protocol, NTLM will continue [2] to be sup¬ 
ported and used for pass-through network authentication, remote file access, and 
authenticated RPC connections to earlier versions of Windows NT. 

NT 5.0 domains can be organized into a hierarchical domain tree. The trust relation¬ 
ships established between domains in the Active Directory allow users with accounts 
defined in one domain to be authenticated in another domain. Domain Trust relation¬ 
ships are established via Kerberos; thus the Kerberos transitive trust (delegation) model 
is in effect. This use of Kerberos will also allow the establishment of realm authentica¬ 
tion between heterogeneous Kerberos realms. 

Kerberos Highlights 

Some of the NT 5.0 Kerberos highlights are: 

■ Each Domain Controller will implement a Kerberos Key Distribution Center (KDC). 

■ NT domains are equivalent to a Kerberos realm, but will still be called domains. 

■ The KDC uses the Active Directory as the account database for users and groups. 

■ Because each Domain Controller is a KDC, physical security is a high priority. 

■ NT 5.0 domains use transitive trust relationships. Thus all NT domains contained 
within the AD will trust each other implicitly[3]. 

■ You can define trust relationships between existing Kerberos realms and NT 5.0 
domains to generate ticket referral requests between realms and domains. 

■ Microsoft plans to implement extensions [4] to support public-key authentication. 


Some of the benefits of 
Kerberos are mutual 
authentication of both 
client and server, reduced 
load on the server during 
logon, and support for 
authorization delegation. 
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Windows NT and UNIX 
integration is not anywhere 
near seamless, but it is 
getting better. 


Heterogeneous “Realm Authentication" 

This is a major win for those who want to be able to utilize single login for integrated 
UNIX and NT 5.0 systems (caveat: Kerberos implementations must support the Inter¬ 
operability Requirements defined in RFC 1510). Although ticket referrals are sup¬ 
ported, non-Windows NT KDCs are not likely to contain the Authorization Data NT is 
expecting[5]. When this occurs, Windows NT will try to use the principal name in the 
ticket and create a security access token for a designated user account or use a default 
account defined for this purpose. NT 5.0 will also integrate with DCE Security Services 
as well. 


Authentication of External Users 

NT 5.0 will provide support for public-key authentication on behalf of users who do 
not have a Windows NT domain account. Users will be authenticated by a public-key 
certificate and can be granted access to NT resources. NT 5.0 has the ability to associate 
one or more external users to an existing Windows NT account for access control. The 
subject name on the X.509 V3 certificate is used to identify the external user associated 
with the account. This many-to-one mapping provides a major benefit for external 
client integration. 


Summary 

Windows NT and UNIX integration is not anywhere near seamless, but it is getting 
better. With the addition of Active Directory and Kerberos, the job is getting easier. 

This is moving in the right direction. With this direction, the Windows NT 5.0 is a plat¬ 
form that can provide a good foundation for secure integration of heterogeneous plat¬ 
forms. 

For more information, see <http://www.microsoft.com/ntserver> and 
<http://www.microsoft.com/security>. 

Notes 

[ 1 ] In NT 5.0, Domain Controllers are also Kerberos Key Distribution Centers. This has 
ramifications on trust relationships. 

[2] Because Windows NT will continue to support NTLM authentication, you will still 
have to deal with the insecurities of NTLM. 

[3] This is a feature of the Active Directory trust model. In NT 4.0 and earlier versions, 
interdomain trust relationships were established explicitly. They are defined by one-way 
trust relationships between Domain Controllers. 

[4] A proposal to extend the Kerberos protocol specification to provide a method for 
using public-key cryptography for initial authentication has been submitted to the 
IETF working group for review. 

[5] Kerberos V5 defines an encrypted field in session tickets to carry Authorization 
Data. NT 5.0 uses that field to hold Security IDs representing the user and group mem¬ 
bership. 
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On Reliability - System Administration ) 

This time around, let’s talk about system administration and how to do it more 
reliably. But that’s what this entire series of articles is about, isn’t it? Maybe I 
should narrow it down a little bit. Let's talk about reliability in the parts of sys¬ 
tem administration that actually takes place on a machine. First, though, let’s 
try to define what system administration is and then discuss what things this 
article isn’t going to be about. 

“System administration” includes all the “overhead” aspects of creating and keeping a 
“system” running and available. Nope. This isn’t working out either. Let’s try another 
approach. 

Once you have your hardware installed and your network working, there are still all the 
day-to-day tasks of installing software, maintaining user accounts and compiling mail¬ 
ing lists, monitoring, and repairing. The software- and configuration-related tasks of 
system administration are what I’m going to attempt to cover this time around. And I 
hope that’s a clear enough definition, because I’m all out of ideas. For lack of a better 
term, I’m going to call this “system administration,” but we all know that it’s just one 
part of the total system administration workload. 

Of course, no reliability article would be complete without a reminder of the basic prin¬ 
ciples: service levels, risk evaluation, costs of failures, finding the right balance, etc. 

So far in this series, I’ve focused on hardware and wiring and touched on tasks and 
processes only superficially. Reliable system administration (at least as I have defined it 
for this article) tends to be much less related to hardware and much more related to the 
tasks themselves and the performance of those tasks. 

I’m going to outline a few key words for reliable system administration, give a few 
examples of how to apply them, and then mention a few topics that don’t fit neatly into 
those categories. (This matches nicely with system administration in general, because 
nothing ever fits together quite as well as you hope it will.) 

Key Words 

Allow me to propose a short list of important key words for reliable system administra¬ 
tion: 

■ Consistency. Set your standards and procedures and stick to them; all sorts of things 
will be easier and more reliable. 

■ Documentation. If it’s not properly documented, it won’t pass either the “run over by 
a bus” test or the “won the lottery” test (i.e., if all the documentation is in your head 
or your mailbox, the system is unlikely to survive your sudden disappearance). 

■ Automation. Never do something twice by hand if you can write a program to do it 
for you. If tasks are (properly and carefully) automated, they’re less likely to fail as a 
result of your being distracted or rushed or having fumbling fingers. 

■ Repeatability. This is often a combination of the previous three. Proper documenta¬ 
tion and automation will help you set up a new machine (or recover or upgrade an 
existing one) far more effectively and reliably. 

Let’s talk about these in a little more detail with a few examples. 


\ 
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I’m convinced that one of 
the most effective tools in 
a system administrator's 
arsenal is consistency. 

Your users will thank you, 
your friends and family will 
thank you, and your 
evenings and weekends 
will thank you, too. 


Consistency 

This really is one of the cornerstones of system administration. If you’re not consistent 
in how you do things, you’re going to be much less effective, much less able to delegate 
tasks, much less able to scale your installation past a small number of systems, and 
much less able to put together systems that run reliably and are easily recoverable in the 
event of a failure. 

Let’s pick on everybody’s favorite topic for an example: backups. (We’ll be able to use 
this same example later for the other key words as well.) If you have inconsistent 
backup methods, using different commands or schedules on all your machines, I would 
venture to guess that you’re going to find doing backups a terrible, onerous chore and 
not do it as well as you would hope to. And if doing backups is a complicated and con¬ 
voluted task, it will be hard for you to pawn the job off on some underworked clerk 
(we all know, of course, that the only truly overworked people in a company are the 
system administrators), giving you less free time. Different backup methods for each 
system mean that once you get beyond a small number of machines, you will likely find 
it simply too complicated to do proper backups. And lastly, if you don’t have one stan¬ 
dard way of doing backups and restores, of cycling your tapes off-site, and of keeping 
track of which backups are on which tapes, you’re going to have a heck of a time 
putting things back together when your company Web site goes boom, and your boss, 
the head of sales, the head of marketing, and the CEO are all standing around breath¬ 
ing down your neck. 

Have I convinced you yet? OK, then how about another perennial favorite: software 
installation, configuration, and distribution (and if you don’t believe me that it’s a 
favorite topic, have a look at the proceedings of any of the 11 LISA conferences, and 
you’re bound to see at least one or two related papers each year). A simple example 
here is the fabulous GNU “autoconf” system, which is used to generate those nice “con¬ 
figure” scripts that you see in so many software distributions. In the olden days, when 
you grabbed some software from the net, you had to read the READMEs, examine the 
Makefiles and .h’s, and manually customize everything to suit your environment. 
Nowadays, if there’s a “configure” script included, you can just about always rely on 

% ./configure —prefix=/local 

% make install 

to do just what you would hope it would do, a concrete example of the time- and 
effort-saving benefits of consistency. 

If you look back at the LISA software installation and distribution papers, one thing 
that they virtually all have in common is a set of rules defining how and where to 
install your software “packages.” Decide on one place to put your source, one structure 
in which to install your binaries and supporting files, and follow your rules religiously. 
It’s much easier to be able to tell someone that the source is under / local/src/pkg 
and the installation is under /local/dist/pkg, than to make everything you do a spe¬ 
cial case. 


Consistency applies to almost everything: day-to-day procedures, how user accounts get 
authorized and created, where your backup tapes are stored, how IP addresses are 
assigned, and on and on. Whether you call them rules, policies, procedures, or prac¬ 
tices, once you set ’em, don’t forget ’em. I spent quite a few years doing centralized sys¬ 
tem administration and software support for hundreds of different machines, with 
different operating systems and revisions, for thousands of users; and I’m convinced 
that one of the most effective tools in a system administrator’s arsenal is consistency. 
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Your users will thank you, your friends and family will thank you, and your evenings 
and weekends will thank you, too. 

Documentation 

If you don’t document everything, you’re not doing your job. You’re making things 
harder for the users (is there anyone who doesn’t get frustrated when the “man” page 
and user documentation are missing and not to be found?) and harder for yourself and 
your co-workers (because you’ll end up answering the same questions over and over); 
and if all the documentation is locked up inside your head, you’re making yourself 
unpromotable and untransferable. 

There always seems to be a strong perception that “documentation is hard” or “I’m not 
a good writer,” or “I don’t have time.” I’ll tell you, from experience, that man pages for 
most programs get to be trivial to write after you’ve knocked off a dozen (or a gross) or 
so. And who hasn’t had the experience of returning to a program or system after a few 
months and being unable to remember or determine what your beautiful, “self-docu¬ 
menting” code is supposed to be doing? 

As I mentioned before, the favorite metric for how much documentation is enough is 
the “if you got hit by a bus” rule - the question being whether your systems would keep 
on running if you got hit by a bus tomorrow. (I prefer to use the “if you won the lottery 
and suddenly quit your job to move to Tahiti” rule because that seems much more 
cheerful.) 

Make a man page (if you’re a UNIX administrator) or a Web page (for anyone else) for 
every command or process that you install. Document each “process” or “job step,” doc¬ 
ument your “cron” jobs and mail aliases, document your installation standards, your 
policies and procedures, your vendor service contract information, and make your life 
easier. Document your backup and recovery practices and processes so your minions 
can take care of things while you sleep. And, of course, once you have an online copy, 
you can make your all-important paper copy so you won’t be completely stranded when 
your root partition dies. Set up a “cron” job or something to automatically (oops, that’s 
the next key word) print an updated copy every few months; obsolete emergency recov¬ 
ery documentation isn’t much fun. And finally, don’t forget to write down the root 
password somewhere so that your systems can survive a bus crash, even if you don’t 
(even though it’s not likely to be a significant legacy handed down through the genera¬ 
tions). 


... the favorite metric for 
how much documentation 
is enough is the "if you got 
hit by a bus” rule - the 
question being whether 
your systems would keep 
on running if you got hit 
by a bus tomorrow. 


Automation 

Automation is your friend. Get it working right once, on one machine, and it will (more 
than likely) keep right on working, and you can usually use the same method on all 
your other machines, old and new. 

Let’s look at backups again. No one wants to type the “runbackup” command every day. 
And it’s a sure thing that no one wants to have to type nonsense like 

% dump 3bfu 32 /dev/rmt2 / /usr /var 

day after day after day. Get the best backup hardware and software your budget allows. 

If your budget is zero, at least use something like (the terrific) “amanda” backup soft¬ 
ware from the University of Maryland [ 1 ]. If your budget is larger than zero, buy expen¬ 
sive backup software, buy a giant jukebox, install fiber to a suitable off-site location, set 
it, and forget it (well, not really, but you get the idea) [2]. The idea is, of course, to make 
computers do the repetitive tasks - computers are good at mindless repetition, and 
humans generally aren’t. 
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Making tasks repeatable 
usually requires a larger 
up-front investment of 
time and energy. 


We’ve all seen Makefiles (or at least, most of us have). If you think about it, make [3] is 
one of the earliest automation tools for UNIX, and it can be used for all sorts of things, 
in addition to building programs from source [4]. Shell scripts combined with cron are 
another easy way to automate repetitive tasks. 

My final example in my argument in support of automation is its use in software distri¬ 
bution. One of the few recurring themes in the myriad of software distribution papers 
in past LISA conferences is that of automation. Updates almost always get distributed 
automatically, usually fired off early in the morning from a cron job. People can be far 
more effective when they have the same software environment everywhere, and, con¬ 
versely, system administrators can be far less effective if they need to copy, compile, and 
install the same software on each machine any time something new or updated is 
installed. 

Repeatability 

There are two ways to think of repeatability — how to redo or repeat tasks on a single 
machine and how to apply (or repeat) the same actions across multiple machines. 

Using our favorite example (backups), repeatability means that your backups can run 
the same way, day after day, with as little manual intervention as possible. This includes 
little things like making sure your log files get rolled from time to time so they don’t 
just grow without bound and fill your disk. Repeatability also means that you can install 
the software and get it working again after an OS upgrade (or recovery), and it also 
means that once you have your backups working on one machine, you can easily get 
them working on all your other machines. 

Making tasks repeatable usually requires a larger up-front investment of time and 
energy. You need to think about and write things like install scripts, Makefiles, setup 
scripts, and so on. In software development, we talk about the development cost being 
only a small part of the total cost and the bulk of the cost being in the ongoing support 
and maintenance of the software. I’ll claim that system administration often has an 
analogous rule - that the bulk of the cost of system administration is often the ongoing 
and repetitive tasks that stretch forward through the years. But I’ll also claim that the 
future costs can be reduced (often substantially) by making a modest investment up 
front in ensuring repeatability. 

Two more quick examples of tasks that realty benefit from repeatability: account cre¬ 
ation (especially in an educational setting or anywhere else with high user turnover) 
and PC and/or workstation setup (typically through software automation, disk cloning, 
or custom boot disks). Very few of us look forward to creating the ten thousandth user 
account or setting up the fifteen hundredth “wintel” PC by hand. (Yes, repeatability is 
often very closely tied to automation.) 

Odds and Sods 

Now that we’ve gone over what I claim are the key words and basic ideas, I’ll quickly 
mention a few more items that don’t seem to fall obviously under one of the key words. 

Use BOOTP and/or DHCP servers to dole out IP addresses and distribute DNS, gate¬ 
way, and other configuration information. Even if you statically allocate IP addresses to 
all your PCs, X terminals, etc., the ease of setup and the ability to renumber or reconfig¬ 
ure easily and automatically when necessary are great ways to increase reliability (and 
your free time) by avoiding having to visit each desktop or having to track down which 
two machines are trying to use the same IP address. 
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\void manual or custom setups whenever possible. Use a standard workstation software 
,etup, and discourage (or prevent) users from changing or adding things. 

3e familiar with tools like rdist and track to automate your file distribution - they’re 
i great way to automatically replace or repair files that have become corrupted or gone 
nissing (as long as it’s not your master host that has problems!). 

Jse a change control system, like RCS, SCCS, or CVS, whenever possible, and always 
:>ut something meaningful in the change logs. It’s a great way to keep track of what 
you’ve changed and an easy way to keep old versions available (and much more reliable 
han a series of .bak files). 

iet up as much automatic monitoring as possible. Use a log file watcher to monitor sys- 
og and other log files and dispatch warning messages in the appropriate ways (email, 
'ephyrgrams, broadcasts, pagers, voice modems, cell phones, etc.). Or even better, have 
four log file watcher fire off repair scripts to fix things automatically. And you should 
ilso periodically run commands or scripts to watch things like mail and printer queues, 
Tee disk space, load average, and so on. (It’s always nice to notice and repair a problem 
before the users notice and start calling.) 

Use a cron job to save copies of important files (like /etc/passwd) to help guard 
against errors, accidental deletions, and filesystem corruption. 

And to help you react appropriately, make sure you have the set of tools that help you 
do your job in the most appropriate way - tools like laptops, network connections at 
dome, cell phones, and pagers can be annoying, but if they save you a late-night trip 
into work, you might be better off. 

For Another Time 

There are some topics that could have been included in this article but are important or 
iarge enough to merit separate discussion. In future articles, I hope to cover backups (in 
much deeper detail), restores, and disaster recovery and discuss how your “people prac¬ 
tices” - training, communication, coordination, who’s on call, etc. - fit into your 
approach to reliability, and, of course, the perennial favorite, security, and a review of 
how your security policies and practices affect the reliability of your systems. 

Finally, if there are any reliability-related topics that I haven’t covered (thereby demon¬ 
strating that I may not be as reliable a source of information as one might hope), please 
let me know. I’d appreciate your input. 

Notes 

[1] <ftp://ftp.cs.umd.edu/pub/amanda/> contains everything about Amanda, including copies 
of “The Amanda Network Backup Manager” by James da Silva and Olafur Gudmunds- 
son from LISA VII, 1993, and “Performance of a Parallel Network Backup Manager” by 
da Silva, Gudmundsson, and Daniel Mosse from the 1992 Summer USENIX Technical 
Conference. 

[2] This kind of approach actually works great, by the way. Details on request. 

[3] S. I. Feldman, “Make - A Program for Maintaining Computer Programs,” 1978. 
Available at <http://plan9.bell-labs.com/7thEdMan/vol2/make>. 

[4] See, for example, “‘Make’ as a System Administration Tool” by Bjorn Satdeva in the 
SANS III proceedings from 1994. 
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( ToolMan Meets PatchReport 

Warning: This issue’s ToolMan is highly platform specific and hard-core sysad- 
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min. If you don’t run and maintain Sun Solaris systems, you might wish to 
move on. 

Boring Technical Stuff 

OK, now that everyone else has gone away, we can get down to business. As you know, 
one of the very tedious aspects of maintaining computer systems is keeping them up to 
date via application of OS patches. This process breaks down into basically three phases: 
(1) identifying patches that are needed, (2) downloading patches, and (3) installing 
patches. You know how much fun this isn’t. The process is tedious, time-consuming, 
error prone, and boring. But I’ll show you a program that can accomplish all of this and 
more in one single, solitary command line. 


Background 

In our department, a medium-sized site, we have (among other systems) about 150 
computers running Sparc and X86 Solaris (SunOS 5.5, 5.5.1, and 5.6). These all need 
occasional patch updates, either to fix some identifiable problems or because, well, it’s 
just that time. Sun makes these rueful patch update tasks more bearable in a few ways. 

(1) They supply a nice Web site from which most patches can be downloaded - whether 
or not you have a support contract (though if you have the contract, you get a few extra 
bennies). (2) They also supply a handy program, patchdiag, which will analyze your 
system and tell you which patches could be applied. And (3) They supply some useful 
tools for applying and maintaining patches on your system, namely, installpatch, 
showrev, and, for Solaris 2.6, patchadd. 

But there are some problems with going through this procedure. One is the use of the 
patchdiag program. You must connect to the SunSolve site (<http://sunsolve.sun.com> or 
<ftp://sunsolve.sun.com>) using your support ID and password, and download the latest 
copy of the patchdiag.xref patch database file and possibly a current copy of the 
patchdiag program. Then there are some deficiencies with the patchdiag output (see 
Listing 1). 


Program: PatchReport 

Abstract: analyze system, download and install patches 

Platforms: Solaris 2.x (SunOS 5.x) 

Language: Perl 5.002+, with 

modules: libnet, Data-Dumper, MD5, and 10 
Author: Joe Shamblin <wjs@cs.duke.edu> 

Availability: <http://www.cs.duke.edu/~wjs/pr.html> 

<ftp://x86. cs. duke. edu/pub/PatchReport/index. html> 

Features are still being added, so check for updates! 
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Listing 1: Excerpt from the output of a run of patchdiag. 
% patchdiag -x patchdiag. xref 


System Name: turkey SunOS Vers: 5.5.1 Arch: spare 
Cross Reference File Date: 30/Sep/97 
PatchDiag Version: 1.0.1 


Report Note: 

Recommended patches are considered the most important and highly recommended patches that avoid the most 
critical system, user, or security related bugs which have been reported and fixed to date. A patch not 
listed on the recommended list does not imply that it should not be used if needed. Some patches listed 
in this report may have certain platform specific or application specific dependencies and thus may not 
be applicable to your system. It is important to carefully review the README file of each patch to fully 
determine the applicability of any patch with your system. 


INSTALLED PATCHES 


Patch 

ID 

Installed 

Revision 

Latest 

Revision 

Synopsis 


103582 

01 

15 

SunOS 5.5.1: 

/kernel/drv/tep and /usr/bin/nets tat patch 

103630 

01 

09 

SunOS 5.5.1: 

ip ifeonfig arp udp icnp patch 

103663 

01 

08 

SunOS 5.5.1: 

libresolv, in.named, named-xfer, ns lookup & nstest pa 

103690 

03 

05 

SunOS 5.5.1: 

cron/crontab/at/atq/atrm patch 

104433 

03 

04 

SunOS 5.5.1: 

pam security patch 


UNINSTALLED RECOMMENDED PATCHES 


Patch 

ID 

Installed 

Revision 

Latest Synopsis 
Revision 



103558 

N/A 

10 

SunOS 5.5.1 


admintool/launcher fixes plus various swmtool fixes 

103594 

N/A 

10 

SunOS 5.5.1 


/usr/lib/sendmail fixes 

103600 

N/A 

18 

SunOS 5.5.1 


nfs, tlimod and rpemod patch 

103612 

N/A 

33 

SunOS 5.5.1 


libc, libnsl, libucb, nis_cachemgr and rpc.nisd patch 

103640 

N/A 

12 

SunOS 5.5.1 


kernel patch 

103680 

N/A 

01 

SunOS 5.5.1 


nscd/nscd__nischeck rebuild for BIND 4.9.3 

103686 

N/A 

02 

SunOS 5.5.1 


rpc.nisd_resolv patch 

103696 

N/A 

02 

SunOS 5.5.1 


/sbin/su and /usr/bin/su patch 

[ ... 29 lines deleted ... 

] 



103901 

N/A 

08 

OpenWindows 

3.5.1: 

Xview Patch 

104338 

N/A 

02 

OpenWindows 

3.5.1: 

libXt patch 

105251 

N/A 

01 

OpenWindows 

3.5.1: 

libXt Binary Compatibility Patch 

UNINSTALLED SECURITY PATCHES 



NOTE: This list includes the Security patches that are also Recommended 

Patch 

Installed 

Latest 

Synopsis 



ID 

Revision 

Revision 



103558 

N/A 

10 

SunOS 5.5.1 


admintool/launcher fixes plus various swmtool fixes 

103594 

N/A 

10 

SunOS 5.5.1 


/usr/lib/sendmail fixes 

103612 

N/A 

33 

SunOS 5.5.1 


libc, libnsl, libucb, nis_cachemgr and rpc.nisd patch 

103640 

N/A 

12 

SunOS 5.5.1 


kernel patch 

103680 

N/A 

01 

SunOS 5.5.1 


nscd/nsccLnischeck rebuild for BIND 4.9.3 

103686 

N/A 

02 

SunOS 5.5.1 


rpc.niscLresolv patch 

103696 

N/A 

02 

SunOS 5.5.1 


/sbin/su and /usr/bin/su patch 

[ ... 22 lines deleted ... 

] 



103901 

N/A 

08 

OpenWindows 

3.5.1: 

Xview Patch 

104338 

N/A 

02 

OpenWindows 

3.5.1: 

libXt patch 

105251 

N/A 

01 

OpenWindows 

3.5.1: 

libXt Binary Compatibi1ity Patch 
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Got Q tool that's useful, 
unique, way cool? ToolMan will 
make you famous! Please send a 
description of your intellectual 
property to <ToolMan@usenix.org>. 


As you can see, the patches are listed in three sections: Installed, Recommended, and 
Security. This layout is not very clear in that there is overlap between the Recom¬ 
mended and Security sections that makes it difficult to decide which patches to install. 
You cannot easily see, for instance, which patches are both Recommended and Security 
without doing a lot of tedious cross-referencing. Additionally, if a patch is already 
installed and an update is available (Installed section), there is no indication as to 
whether such a patch is Recommended or Security or both. And even if these were not 
problems, you still have to go through the rigamarole of downloading the patches and 
running the installations. If you need to do this for multiple OS releases for multiple 
hardware architectures, it becomes easy to let this slip down to a lower spot on your 
priority list. This is quite unfortunate in a scenario, for example, of Internet-connected 
computers needing security patches! 

A Break in the Clouds 

One of my co-workers, Joe Shamblin, is our OS and security guru and is generally the 
one burdened with the chore of keeping our systems up-to-date with the latest patches. 
He has brilliantly automated and simplified this odious task. 

Joe created - and regularly employs - a not-so-trivial Perl script called PatchReport, 
so named because in its initial incarnation its sole function was to produce a report a la 
patchdiag, but with two improvements: it automatically downloaded the xref file, 
and it provided a more usable, consolidated report. The table produced by PatchRe¬ 
port combines the information from all three sections of the patchdiag report, indi¬ 
cating in a single line for each patch if it is Recommended, Security, and/or if a prior 
version is already installed. This makes it much easier to scan the list and decide which 
patches are appropriate for your system. 

But PatchReport has evolved into a full-fledged patch analyzer (the report), down- 
loader, and installer. As noted earlier, it can accomplish all of this and leave a Solaris 
system completely up to date via a single command. Invoked with appropriate options 
specified, PatchReport will: connect to the Sunsolve site, download the 
patchdiag.xref and CHECKSUMS files, analyze patches on your system and produce a 
report, download selected patches, check the md5 checksums, and install the patches. 
You can even tell it to shut down and reboot the system when its done! Listing 2 shows 
an example of a PatchReport run. 

By the way, if PatchReport finds that your system is completely up to date, well, you’ll 
just have to find out for yourself what happens. 

You can also use PatchReport in conjunction with Suns JumpStart suite (used to install 
new systems). PatchReport can download appropriate patches to a directory. Then 
JumpStart can be configured to install these patches to the OS during the initial instal¬ 
lation. Alternatively, JumpStart could be configured to call PatchReport directly. 

PatchReport is written for Solaris and not extended to other operating systems because 
Sun has a very open and well-documented patch system that makes programs like 
patchdiag and PatchReport possible. Other vendors, please take note. 

Closing Remarks 

To paraphrase someone who was paraphrasing Dave Barry, systems administration 
consumes time like Dave Barry’s dog gobbles taco chips. If your job involves installing, 
maintaining, and updating Solaris-based systems, here’s a power tool that can save you 
hours at a pop. But you better hurry and pick up a copy before SprintNet goes down 
again! To paraphrase another sage, “you snooze, you looze.” 
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Listing 2: Excerpt from the output of a run of PatchReport 
# PatchReport -Ari 

Please provide the account and password in the form " ID/pas swd H 
account/passwd? *******/******* 

Analyzing needed patches on your machine, this might take a minute or two depending on the options you 
chose, and/or your net connection. 

Patch-ID Security Recommended ID Description 


103558-10 Security Recommended SunOS 5.5.1: admintool/launcher fixes plus various swmtool 

103582-15 Security Recommended 01 SunOS 5.5.1: /kernel/drv/tcp and /usr/bin/netstat patch 

103594-10 Security Recommended SunOS 5.5.1: /usr/lib/sendmail fixes 

103600-18 N/A Recommended SunOS 5.5.1: nfs, tlimod and rpcmod patch 

103612-33 Security Recommended SunOS 5.5.1: libc, libnsl, libucb, nis_cachemgr and rpc.ni 

103630-09 Security Recommended 01 SunOS 5.5.1: ip ifconfig arp udp icmp patch 

103663-08 Security Recommended 01 SunOS 5.5.1: libresolv, in.named, named-xfer, ns lookup & n... 

103680-01 Security Recommended SunOS 5.5.1: nscd/nscd_nischeck rebuild for BIND 4.9.3 

103686-02 Security Recommended SunOS 5.5.1: rpc.nisd_resolv patch 

103690-05 Security Recommended 03 SunOS 5.5.1: cron/crontab/at/atq/atrm patch 

[ ... 21 lines deleted ... ] 

103901-08 Security Recommended OpenWindows 3.5.1: Xview Patch 

104338-02 Security Recommended OpenWindows 3.5.1: libXt patch 

105251-01 Security Recommended OpenWindows 3.5.1: libXt Binary Compatibility Patch 

**Retrieving Patches** 

Patch-ID Checksum status Description 


103558-10 checksum match SunOS 5.5.1: admintool/launcher fixes plus various swmtool 

103582-15 checksum match SunOS 5.5.1: /kernel/drv/tcp and /usr/bin/netstat patch 

103594-10 checksum match SunOS 5.5.1: /usr/lib/sendmail fixes 

103600-18 checksum match SunOS 5.5.1: nfs, tlimod and rpcmod patch 

103612-33 checksum match SunOS 5.5.1: libc, libnsl, libucb, nis_cachemgr and rpc.ni 

103630-09 checksum match SunOS 5.5.1: ip ifconfig arp udp icmp patch 

103663-08 checksum match SunOS 5.5.1: libresolv, in.named, named-xfer, ns lookup & n... 

103680-01 checksum match SunOS 5.5.1: nscd/nscd__nischeck rebuild for BIND 4.9.3 

103686-02 checksum match SunOS 5.5.1: rpc.nisd_resolv patch 

[ ... 22 lines deleted ... ] 

103901-08 checksum match OpenWindows 3.5.1: Xview Patch 

104338-02 checksum match OpenWindows 3.5.1: libXt patch 

105251-01 checksum match OpenWindows 3.5.1: libXt Binary Compatibility Patch 

** Installing all patches without checking them first ** 

** can have negative consequences. I am assuming that ** 

** you know this, and think that all of these patches ** 

** are a good idea. Using the -F option will turn off ** 

** this message. ** 

Which patches do you want to install (all/none/list of patches) all 
**Installing Patches (this can take a while)** 

Patch-ID Install status Description 


103558-10 Patch installed SunOS 5.5.1: admintool/launcher fixes plus various swmtool 

103582-15 Patch installed SunOS 5.5.1: /kernel/drv/tcp and /usr/bin/netstat patch 

103594-10 Patch installed SunOS 5.5.1: /usr/lib/sendmail fixes 

103600-18 Patch installed SunOS 5.5.1: nfs, tlimod and rpcmod patch 

103612-33 Patch installed SunOS 5.5.1: libc, libnsl, libucb, nis__cachemgr and rpc.ni 

103630-09 Patch installed SunOS 5.5.1: ip ifconfig arp udp icmp patch 

103663-08 Patch installed SunOS 5.5.1: libresolv, in.named, named-xfer, nslookup & n 

103680-01 Patch installed SunOS 5.5.1: nscd/nscd_nischeck rebuild for BIND 4.9.3 

103686-02 Patch installed SunOS 5.5.1: rpc.niscLresolv patch 

103690-05 Patch installed SunOS 5.5.1: cron/crontab/at/atq/atrm patch 

( — 21 lines deleted ... ] 

103901-08 Patch installed OpenWindows 3.5.1: Xview Patch 

104338-02 Patch installed OpenWindows 3.5.1: libXt patch 

105251-01 Patch installed OpenWindows 3.5.1: libXt Binary Compatibility Patch 
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with him via the email 
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A Brave New World: 

UNIX Developers in an NT Land _ 

Take a bunch of developers used to the UNIX programming environment, move 
some of them over to NT, and you end up with less productive programmers 
who grumble a lot. Here are some of the problems we faced and what we were 
able to do about them and, in some cases, what we weren't able to do about 
them. No claim is made that our solutions or workarounds are universally the 
best ones or even the best one for any developers you might be supporting who 
are making the same crossing into a new world. 


Shells and Stuff 

MS-DOS’s COMMAND.COM is reviled by many, and CMD.EXE (the default NT command 
shell) isn’t a whole lot improved. This is too bad because there have been many share¬ 
ware and freeware replacement command shells for COMMAND.COM that have been avail¬ 
able for years (my favorite from a past life was the 4D0S/4NT/40S2 shells from JP 
Software), and it would have been nice if CMD.EXE would have learned yet more from 
them. That’s not to say there aren’t a few improvements: for example, CMD.EXE windows 
support using the mouse to initiate marking text for cut and paste (although you have 
to use enter to end the marking, and you can mark only rectangles), and tab does file 
completion, provided you tweak the right magic registry settings. 

(Sure, uh huh, NT is much easier to administer than UNIX; after all UNIX has those 
horrible, obscure text configuration files, but NT has nice GUIs and, oh, by the way, 
equally obscure registry settings. Moral: obscurity isn’t inherently a UNIX vs. NT 
thing.) 

Some of us use CMD.EXE anyway, but others use a freely distributable port of tcsh. 
Although there are supported commercial packages like the MKS toolkit that include 
various shells, UNIX utilities, etc., so far we’ve opted to go with freely distributable 
ports of various utilities. Those of you who remember ports of various UNIX tools to 
MS-DOS (with considerable code rewriting necessary in the port effort and often with 
much functionality lost) shouldn’t let those memories unfairly prejudice you against the 
ports that are now available. Porting to Win32 at the very least allows not having to 
mangle 32-bit code back into 16-bit code, and although the NT POSIX subsystem is 
incomplete, it’s adequate for some utilities, and Win32 console mode is adequate for 
others. Even a fairly good freely distributable port of emacsl9 is available, as are good 
ports of vi and derivatives. 

Having a nice directory full of such gathered stuff on a server and exporting it to every¬ 
body reduces some of the grumbling. And that brings us to the next topic. 

File Sharing 

Fundamentally, we saw two choices between what protocols were going to flow over the 
network: NFS, which we all know and just love, or SMB, which stands for Server Mes¬ 
sage Block and is the foundation of Microsoft LAN Manager and subsequent native 
Windows and NT file sharing for both peer/peer and client/server. If we went primarily 
with NFS on the network, we would have to buy NFS clients for all NT systems and 
possibly NT NFS servers for at least some of the NT systems. The pro was that then 
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everybody could talk to everybody; both UNIX and NT systems could act as servers and 
as clients as long as we were willing to spend the money. The cons were the money and 
that we had heard claims of instability with adding NFS to NT, claims we weren’t inter¬ 
ested in confirming or denying ourselves. 

We decided to go with SMB. Both commercial and freely distributable SMB servers exist 
for UNIX; we opted to try out Samba, which falls into the latter category, to simplify 
administration-anybody who wanted to try it out on a UNIX system could; we didn’t 
have to count heads to see how many licenses we needed to buy. Samba enables the 
UNIX system to act as a fileserver (and print server, too, although we are not using that 
functionality); from an NT system, accessing a share (the term “share” is roughly equiv¬ 
alent to an exported filesystem specified in /etc/exports for NFS) on Samba server is 
just like accessing a share on an NT system. 

The con with going with Samba is that there’s no similarly transparent way for an NT 
system to serve files to a UNIX system. Samba supplies smbclient, whose UI is much 
like the standard UNIX FTP client. So on a UNIX system you can get and put files to an 
NT fileserver, but this is a bit awkward. 

In any case, in practice, this inability to access NT shares transparently from a UNIX 
system has not been a major problem for our development workflow. For rarely 
accessed files, people will use smbclient; for more commonly accessed files, we can have 
the NT system serve the files via HTTP. One major reason we haven’t stressed too much 
about transferring files back and forth is that our revision control system handles that 
without needing to have shared network filesystems. 

Source Code Revision Control 

Source code revision control systems are nearly as touchy an issue as favorite program¬ 
ming editors. They are actually worse in that you need to impose the same system on 
entire groups of developers, whereas individuals within that group can use their own 
favorite editors in semipeaceful coexistence with only occasional firefights. We had an 
in-house system that evolved over years with which developers weren’t entirely happy, 
but at least they were used to it. But adapting it to work with NT seemed to be an 
intractable problem not worth butting our heads up against. We solicited opinions, 
looked for Web pages, read vendor glossies, even had some small, hungry companies 
come give us presentations. Finally, we opted to adopt Perforce. Their Web site will pro¬ 
vide all the glowing points you want, but we particularly liked the number of supported 
platforms for both client and server, efficient use of network bandwidth across WANs 
(single TCP connection per client invocation), atomic changes, ease of writing scripts to 
add functionality, and the lack of requiring that you structure your development cycles 
and workflow the way they think you should. So far, we have no major regrets after 
months of usage. 

A little gotcha about NT that we noticed only in the context of the source code revision 
control system is the annoying case insensitive but case-preserving semantics of NT 
filesystems. If developer #1 checks in \lib\foo.c from an NT system and developer #2 
checks in \LiB\bar .c from another NT system, developer #3 on an NT system, who 
gets top of trunk, will see both files in the same directory, with the exact case of that 
directory’s name being either lib, LIB, or possibly something else if developer #3 already 
had the directory created. But a developer on a UNIX system ends up with two files in 
two different directories and is left to wonder why he can’t perform a full build any 
more. Perforce suggests several workarounds for this problem, one of which works fine 
for us, but it’s nevertheless an annoyance. 


A little gotcha about NT 
that we noticed only in 
the context of the source 
code revision control 
system is the annoying 
case insensitive but case¬ 
preserving semantics of NT 
filesystems. 
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With a little bit of work in 
setting up the software 
environment, NT can 
become a reasonably 
tolerable environment for 
software development. . . 


Working Remotely 

We have a fair amount of telecommuting. Most people work only occasionally from 
their homes, but several people live hundreds of miles away and are only in the office a 
few times a year. Being able to access resources across a dial-up session is therefore 
important. UNIX provides flexibility in how to access resources remotely: you can run 
everything on your local home system and go across the dial-up for remote filesystem 
access, or you can remotely login to a system at work (rlogin/telnet) and run text mode 
applications and tools or even X applications and tools, if you have the patience. NT 
supports the former just fine (SMB on TCP/IP on PPP is no problem), but doesn’t sup¬ 
port the latter out of the box. We knew there existed various commercial packages that 
support remote access for Windows by duplicating the entire desktop that appears on 
the graphics monitor across the dial-up session to be displayed on the home system and 
that over the years their speeds have even come to be about as tolerable as, perhaps even 
better than, running an X app across a similarly low bandwidth network connection. 

We never got around to checking if such packages work on NT, though, because some¬ 
body stumbled across commercial software from Ataman Software that served our 
needs nicely-a Telnet daemon that runs on NT and allows you to Telnet into it. This is 
not to be mistaken for the beta Telnet daemon that is available with one of the NT 
resource toolkits that Microsoft sells in book+CD-ROM form, which is horribly unsta¬ 
ble. The Ataman Telnet daemon is pretty stable, and establishes a session running your 
favorite shell, within which you can run console mode programs. You can’t run IDEs or 
GUI debuggers, but at least you can fire off compiles using a command line compiler 
front end. Even when at the office, the Telnet daemon is quite handy; you don’t have to 
switch keyboards and mice and possibly even have to turn around and move your chair 
to use another NT system. Because NT supplies a Telnet client, remote login in all com¬ 
binations works fine. 

Conclusion 

Developing on NT isn’t nearly as bad as developing for DOS or Windows 3.x is. No hor¬ 
rible hacks like using the keyboard controller to forcibly reset the CPU between pro¬ 
tected and “real” mode, no near vs. far pointers and plethora of “memory” models, no 
A20 gate, expanded, extended, and “high” memory to worry about in your applications; 
that stuff is gone. Networking and file sharing don’t have to be bolted on after the fact 
any more. With a little bit of work in setting up the software environment, NT can 
become a reasonably tolerable environment for software development, even for UNIX- 
biased developers - a backhanded compliment, to be sure, but a compliment neverthe¬ 
less. 

[Author's note: A search engine like AltaVista should suffice to help you find vendor Web 
sites, distribution sites for freely distributable software, etc.] 

[ Disclaimer : Mentions of products should not be taken as endorsements. The author 
has no commercial relationships with vendors of add-on products mentioned other 
than as a paying customer in some cases.] 
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musings 


Recently, I labored at removing barbed wire fences. These rusty relics once sep¬ 
arated one ranch from another and stopped cattle from disappearing into the 
wilderness. It cannot be said that the fences prevented the cattle from destroy¬ 
ing the land they grazed, which will take hundreds of years to recover. Before 
there were cattle, the land was covered in knee-deep grass, and even the trees 
were more abundant and varied. Now the land is rocky and barren. 

The fences in my backyard no longer correspond to any boundary. I am removing them 
so that my neighbors don’t get confused and decide to build a real fence along the old, 
partially fallen down, fence line. I like the illusion fenceless backyards bring-that your 
house simply sits on the land, animals can move uninhibited from one yard to another, 
and there are no visible boundaries. 

There are times and places for boundaries. My house serves as a boundary against bugs, 
critters, and weather, as well as surrounding and protecting my possessions. I have the 
opportunity to control who enters my house and how long they may stay. More than 
my yard, the house defines my true boundary-the yard is a buffer zone. 

But there are other boundaries. The history of computers is replete with boundaries as 
artificial as any other made by human beings. And these boundaries have not served us 
well. Nor, in the long run, do they serve the vendors who created them. 



<rik@spirit.com> 


by Rik Farrow 
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Fences 

Early computers were standalone by nature. It was quite enough to build, design, and 
operate a single mainframe, and nobody expected that one manufacturer’s product 
could exchange data with another. In some cases, it was hard to exchange data even 
between the same makes of computers-unless you consider punched cards or paper 
tape efficient. Over time, standards for magnetic tape evolved, making it possible to 
exchange data between computers. 

Rather than making it easy to connect computers, vendors strove to make them differ¬ 
ent. Repeat business is the foundation for any enterprise, and having customers who 
could buy their software, supplies, and replacements from only one vendor guaranteed 
repeat business. IBM and DEC had their own terminals. Legal battles were fought 
against vendors who dared to build compatible components such as memory or disks. 
Margins, the markup percentage, stayed high. 

Revolution 

Microcomputers created an avalanche of change. The earliest microcomputers were 
practically useless-interesting, but not good for getting any work done. There was no 
software. 

One of the earlier successes was an operating system called CP/M, originally written on 
DEC hardware and ported to the Intel microprocessor. If you had a floppy drive that 
was aligned correctly, you could load CP/M, use software, and exchange data with other 
people and their computers. The key here was a combination of hardware (the floppy 
drive and the processor) and the operating system, CP/M. 

IBM changed everything. I was working with one of the early microprocessor vendors 
when the PC came out. The engineers and I laughed when we learned that PC power 
supplies were blowing up. The VP of marketing overheard us and sternly reminded us 
that IBM could afford to give away PCs, and they would one day own the market. 
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Over time, the standards 
process, especially the 
excellent Internet stan¬ 
dards process, has become 
more bogged down with 
vendor battles. Vendors 
plot to create a “standard” 
that will directly benefit 
their own designs or work 
to the detriment of a com¬ 
petitor. 


Well, not quite. The PC created a de facto hardware standard. Once the BIOS had been 
successfully reverse engineered, PC compatibles could be built, and competitors almost 
shut out IBM from the market it had created. Margins today on desktop PCs are razor 
thin. For consumers, this is a great deal. 

The basis for software compatibility was MS/DOS, a simple operating system that was 
chosen because the owners of CP/M had trouble with the IBM contract negotiations. 

Bill Gates didn’t have an operating system, but he quickly bought the rights to MS/DOS, 
and changed the course of history. MS/DOS permitted software to be written for the 
new machines, making the new PCs actually useful. 

Networks 

As computers became more common, vendors conceived of wiring the computers 
together, creating a network. These early plans did not involve multiple vendors. The 
ARPAnet did manage to connect many computers, using one vendor’s computer (BBN) 
as a front end. But vendors other than BBN were really not much involved in this 
process. 

The early Internet had a much different model for breaking down boundaries. People 
would design software, use it, and propose that it was good enough for use by others. If 
the proposal was accepted, it was considered a standard. Although a document, the 
RFC, represents a standard, the operational basis is being able to communicate success¬ 
fully with other systems using existing versions of the software. 

Something similar happened with networking hardware. Although there are written 
standards, the real measure of compatibility for a network interface is being able to 
interoperate with other existing products. Of course, establishing this baseline was 
not as easy as I am perhaps making it sound. Again, standards evolved from working 
examples. 

Having vendor-neutral standards has been very good for us. Standards foster competi¬ 
tion, keep prices lower, and actually help us get work done. The focus is not on getting 
our computers and software to communicate, but on getting real work done. 

Boundaries 

Over time, the standards process, especially the excellent Internet standards process, has 
become more bogged down with vendor battles. Vendors plot to create a “standard” that 
will directly benefit their own designs or work to the detriment of a competitor. Not 
long ago I heard a salesperson say “they had just IETF’d” a competitor. He meant they 
had passed through a committee a “standard” that would directly benefit his company 
and hurt a smaller competitor. 

In this case, standards become boundaries that help only certain vendors. 

Another way of creating boundaries is to create a de facto standard, but not publish it. 
Microsoft has become a master of this technique by simply not publishing interfaces. 
The NT API is not published-the Win32 subsystem API is layered on top of the unpub¬ 
lished NT API. SMS (Simple Management System) requires the use of Microsoft’s SQL 
server-and they refuse to publish schemas that would make other databases useful. 

UNIX vendors have played this game, but in a different way. Workstations and servers 
were designed so that the only source for add-on memory or disks was the vendor. Tha : 
has changed to a large degree, and there are second sources for most UNIX workstation, 
and even server, add-ons. 
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Even worse, UNIX vendors fought to create and maintain many minor differences in 
the versions of UNIX used. Although this may have appeared a religious war, it was not, 
no more than the Bosnian conflict is really about Christians and Moslems, but more 
about a surfeit of people and a scarcity of resources. Religion provides a useful demar¬ 
cation, and the losers will no longer compete. 

At this time, I would be happy to have network and administrative interfaces that work 
reliably between all versions of UNIX. The networking does work well, really, but the 
administration is another matter. NT strives to have coherent administration, but only 
among Microsoft products. Microsoft strives to create artificial barriers between other 
vendors’ products and its own. 

I don’t really have any solution to offer. Tearing down old fences made me think about 
the other artificial boundaries that have been created in the world of computers, soft¬ 
ware, and operating systems. Achieving interoperability is not easy, but history has 
shown us it can be done. When it is done, business flourishes (PCs, the Internet), and 
when it is not done, businesses often suffer (IBM and DEC). 

In the world of security, it is a truism that if customers do not demand security from 
vendors, they will not get good security. Perhaps we should also be asking for real stan¬ 
dards and products without artificial boundaries. 

Will this be good for vendors, too? Economists tell us that a nation’s economic success 
can be measured by its product. I disagree. A nation’s wealth is measured by 
exchange-the exchange of products and services. If no one buys your product, you will 
have a valueless product. History has shown us that products that embrace standards 
have done better, that is, contributed more to exchange, over time than closed, propri¬ 
etary products. Standards-based products are easier to exchange. 

Over time, I believe that vendors who create artificial boundaries will suffer, as they 
have in the past. I just don’t like dealing with them while this happens. Do your part. 
Insist on open standards. And I’ll keep on tearing down old fences. 


Achieving interoperability 
is not easy ; but history has 
shown us it can be done. 
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Computing Olympiad training camps and 
a world championship tournament in 
Holland. He also has been one of the 
luckiest secondary students in the world: 
his part-time job is at AT&T Bell Labs. This 
conversation between Russ and Rob 
Kolstad was held via email during 
September of 1997. 


a conversation with 
Russ Cox 

Rob You’ve been associated with USENIX for several years now via the USA 
Computing Olympiad (USACO). Have you spent lots of time on USACO? Have those 
experiences had any value? 

Russ Yes to both questions. Over the past three years, I’ve spent five weeks at 
national or international programming contests as well as time grading lesser ones. I 
attended the USACO training camp and final round, held at the University of 
Wisconsin, Parkside, in 1995, 1996, and 1997. In 1995,1 had the opportunity to repre¬ 
sent the United States at the International Olympiad in Informatics (IOI), held in the 
Netherlands. Shortly after Thanksgiving, I will be travelling with the US team to South 
Africa for the 1997 IOI. 

In addition to time spent at contests and preparing for them, I graded our two Internet 
contests this year as well as the USACO Competition Round. Grading is somewhat 
automated, but still requires 15 to 20 hours of human time for each contest. I hope to 
fully automate the process for the coming year. 

These experiences have had tremendous value for me. I had a great time at the USACO 
training camps during the past three years. At both the USACO training camp and the 
IOI, I’ve had a chance to meet and get to know bright computer programmers from all 
over the United States and around the world. 

At the same time, I’ve learned quite a bit about algorithms and programming style 
from the contests. All the formal instruction I’ve ever had about topics like algorithmic 
complexity or geometric algorithms has come from USACO’s training camp. 
Furthermore, discussions from training camp, whether during a lecture or over lunch, 
have sparked self-study of myriad topics from hashing to finite state machines to 
machine instruction timings. 

Finally, there was 1996. As I mentioned before, I made the IOI team in 1995. Thanks to 
a combination of other distractions and overconfidence, I didn’t prepare myself enough 
for the 1996 final round and performed extremely poorly. As a result, I didn’t make the 
IOI team that year. I worked hard in preparing for 1997’s training camp and happily 
made the IOI team once again. The whole sequence was a great lesson in both humility 
and persistence. 

Rob And now you’re headed to college? 

Russ Yes. I just graduated from high school last June, and am starting my first year 
at Harvard. I wanted a liberal arts school so that I’d have a wide range of nontechnical 
courses to choose from. If the technical sides are ever lacking, it’s relatively painless to 
cross-register for classes at MIT. 

Rob Flow will you choose a major? 

Russ I’m not really sure how I’m going to choose a major. I’m leaning towards com¬ 
puter science right now-and math is definitely in the running-but anything is possible. 
No matter what the major, I plan to take all my electives outside it. Two years ago I was 
fully convinced that courses like History and English were just not for me and didn’t 
pay much attention to them. Some great teachers during the last two school years 
turned me around completely, and I definitely expect to take a broad variety of courses. 

Rob What do you anticipate will be the high points at Harvard? Low points? 

Russ My high school courses were great, but often left me pursuing further explo¬ 

ration of the material on my own. The library was often useless; if I knew a teacher 
who might have information on the subject, that often helped. But usually I never 
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found what I wanted to know. fm looking forward to a much richer font of informa¬ 
tion at Harvard. 

Furthermore, I’m excited about the chance to meet and interact with so many bright 
people from so many different places. USACO, IOI, high school, and my various sum¬ 
mer jobs have shown me that I enjoy being around really smart people from all over. 
One of the highlights of the past school year was arriving at school an hour early each 
day and sitting around with a handful of friends having philosophical discussions 
about current events, ancient history, or even a random Simpsons episode that some¬ 
one had brought in. When I visited Harvard, I got the impression that this was a very 
realistic expectation for the future as well. 

At the same time, I’m hoping that the environment shift won't be too much of a shock. 
I haven’t been thrown into a wholly new environment in six years, but rather have been 
task switching between four or five established ones. I’m leaving all of these behind to 
explore a new one. I don’t expect it to be a large problem, but it’s a skill I’ll have to 
relearn. The same applies on a smaller scale to my computing environment, but again, I 
expect it to be more a chore than an insurmountable obstacle. 

Rob Have you been able to apply any of your computer skills in school or in the 
workplace? 

RUSS Yes. I spent a good part of my senior year in high school setting up an Internet 
gateway and an email subsystem for the school and even got course credit for it. In 
addition, I’ve spent the last three summers working for Bell Labs and now AT&T 
Labs-Research. 

Rob What did the Internet gateway for school entail? Did you learn much? 

RUSS I started with a stock Linux system. Initially, I worked quite a bit on replacing 
some of the more complex Linux daemons with simple, more secure, home-grown 
ones. The whole login process was shell scripts augmented by a couple five-line C pro¬ 
grams, complete with md5sum-based challenge/response authentication. 

I also hacked up 70% of a sendmail replacement inspired by Dave Presotto’s Upas mail¬ 
er, but ultimately concluded it was too big a job. I had everything done save walking the 
outgoing mail queues (we were still passing outgoing mail to BSD sendmail), but found 
that good error recovery was increasingly a problem. If I had been there for another 
year, I would probably have stuck it out with my mailer and login programs, but I 
decided the system had a much better chance of surviving without me if it was running 
daemons that were at least well understood. Unfortunately, I didn’t really have enough 
time to produce a robust system. Now the only extensive shell scripts that remain in use 
are the ones that perform local delivery to Novell Netware. 

I learned an incredible amount about TCP/IP, mail routing, and shell scripts, as well as 
way too much about the Windows 95 TCP/IP stack. I still get a phone call once in a 
while when things break and the student who took over for me isn’t available. 

Rob And at work? You mentioned AT&T Research and Bell Labs. 

RUSS For the last year or so, I’ve worked with cable modem trials for AT&T 
Labs-Research. We telecommute using cable RF downstream and 28.8kbps POTS 
modems back upstream. The speed is really nice. If you play with the TCP window 
sizes, you can get a full two megabits per second datastream into a PC. The result is 
incredibly nice Web/Ftp access-you begin to notice sites that are “only” connected to 
the net via ISDN or a Tl. You get hit whenever you want to upload something, but it’s 
easy enough to avoid. 


December 1997 ;login: 


31 



Russ Cox 



I've internal¬ 
ized the UNIX 
“do one thing well” philos¬ 
ophy to a much greater 
extent than I had three 
years ago. This has made 
my programs ultimately 
simpler ; more concise, and 

yet much more useful. 77 


Besides the cable modem work, I do a lot of system administrivia. In addition, I’ve been 
involved with maintenance of the servers that handle challenge/response authentication 
for our Internet firewall. There are also lots of small “one afternoon” projects: augment¬ 
ing Research UNIX’s lp to be able to send jobs to BSD lpr hosts, writing a quick and 
dirty SNMP client to maintain modem racks remotely, things like that. 

Finally, I multitasked work for AT&T this summer against playing with Brazil, Bell 
Labs’s internal successor to Plan 9.1 have it running on a laptop and recently have been 
playing with DHCP and other issues related to portable computing. Mostly, it’s 
involved hacking at the IP stack and other network-related programs; it’s a lot of fun. 

Rob How have these experiences been of value to you? 

Russ First of all, I’ve learned incredibly much about dealing with users. At school, I 
supported the entire faculty and student body, and at AT&T I’ve been involved with 
technical support for others involved in the cable modem trials. The skills you learn in 
user support-clearly defining the problem, unambiguous communication, asking effec¬ 
tive questions, patience-are also helpful people skills for life in general. 

The second benefit has been to my programming. Since I first installed the public 
release of Plan 9 in April of last year, I’ve read quite a bit of the kernel and other 
sources. Reading quality code has improved my programming skills amazingly. There is 
just no comparison between programs I wrote two or three years ago and the programs 
I’ve written recently. Furthermore, thanks to both reading code and, more importantly, 
interacting with so many people from the pre-split Bell Labs computer science center, 
I’ve internalized the UNIX “do one thing well” philosophy to a much greater extent 
than I had three years ago. This has made my programs ultimately simpler, more con¬ 
cise, and yet much more useful. 

Rob Do you participate in any activities outside the computer world? 

Russ Yes. I’m currently an assistant scoutmaster with the Boy Scout troop in town. 
As a scout in that troop, I earned the Eagle Scout rank and spent my last five years in 
various leadership positions. In high school, I was the editor of the school newspaper 
and managed the baseball team. I also sang in the school choir. For the last five years, 
I’ve worked for some fraction of each summer as a lifeguard at a Boy Scout camp in 
upstate New York. I put in a full season this year-five weeks- as a good way to end my 
time there, at least for now. 

Rob Would you like to share any dreams you have with our readers? 

RUSS Ultimately, I don’t know what I want to do when I get out of school. It might 

be research or teaching or something entirely different. I just don’t know. There are 
some persistent dreams, however: 

■ A year or so ago, I had this one moment of great clarity where I was convinced that 
P == NP, but I don’t remember the reasoning behind it. 

■ A friend and I have been tossing around the idea of writing a book about the kind of 
programming issues that are involved in programming contests and that genre of 
problems in general. 

■ Someday, I’m going to bowl a 300. A bunch of high school friends and I went bowl¬ 
ing semiregularly over the summer, and I bowled a 180 my last time out. 

■ Somewhere in the future, I’d like to grab a couple friends and hike the entire 
Appalachian Trail. It runs from Maine to Georgia, and people doing the entire thing 
usually take several months. 
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using C++ as a better C 


In this column, we’ll spend some time talking about C++ classes, structs, and 
unions, illustrating several points unrelated to object-oriented programming. 

Type Names 

In C, a common style of usage is to say: 

struct A { 
int x; 

}; 

typedef struct A A; 

after which A can be used as a type name to declare objects: 

void f() 

{ 

A a; 

} 

In C++, classes, structs, unions, and enum names are automatically type names, so you 
can say: 

struct A { 
int x; 

}; 

void f() 

{ 

A a; 

} 

or: 

enum E {ee}; 

void f() 

{ 

E e; 

} 

By using the typedef trick, you can follow a style of programming in C somewhat like 
that used in C++. 

But there is a quirk or two when using C++. Consider usage like: 

struct A { 
int x; 

}; 

int A; 

void f() 

{ 

A a; 

} 

This is illegal because the int declaration A hides the struct declaration. The struct 
A can still be used, however, by specifying it via an “elaborated type specifier”: 

struct A 

The same applies to other type names: 

class A a; 
union U u; 
enum E e; 



A 
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Taking advantage of this feature, that is, giving a class type and a variable or function 
the same name, isn't very good usage. Its supported for compatibility reasons with old 
C code; C puts structure tags (names) into a separate namespace, but C++ does not. 
Terms like “struct compatibility hack” and “1.5 namespace rule” are sometimes used to 
describe this feature. 

Bit Field Types 

Here's a small difference between C and C++. In ANSI C, bit fields must be of type 
“int,” “signed int,” or “unsigned int.” In C++, they may be of any integral type, for 
example: 

enum E {el, e2, e3}; 

class A { 
public: 

int x : 5; 

unsigned char y : 8; 

E z : 5; 

}; 

This extension was added in order to allow bit field values to be passed to functions 
expecting a particular type, for example: 

void f(E e) 

{ 

} 

void g() 

{ 

A a; 

a . z = e3; 
f(a.z); 

} 

Note that even with this relaxation of C rules, bit fields can be problematic to use. 

There are no pointers or references to bit fields in C++, and the layout and size of fields 
is tricky and not necessarily portable. 

Anonymous Unions 

Here's a simple one. In C++, this usage is legal: 

struct A { 
union { 
int x; 
double y; 
char* z; 

}; 

}; 

whereas in C, you’d have to say: 

struct A { 
union { 
int x; 
double y; 
char* z; 

} u; 

}; 

giving the union a name. With the C++ approach, you can treat the union members as 
though they were members of the enclosing struct. 

Of course, the members still belong to the union, meaning that they share memory 
space and only one is active at a given time. 
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Empty Classes and Structs 

In C, an empty struct like: 

struct A {}; 

is invalid, whereas in C++, usage like: 

struct A {}; 
or: 

class B {}; 

is perfectly legal. This type of construct is useful when developing a skeleton or place¬ 
holder for a class. 

An empty class has size greater than zero. Two class objects of empty classes will have 
distinct addresses, as in: 

class A {}; 

void f() 

{ 

A* pi = new A; 

A* p2 = new A; 

//pi != p2 at this point ... 

} 

There are still one or two C++ compilers that generate C code as their “assembly” lan¬ 
guage. To handle an empty class, they will generate a dummy member, so, for example: 

class A {}; 

becomes: 

struct A { 

char _dummy; 

}; 

in the C output. 

Name Hiding 

Consider this small example: 

#include <stdio.h> 
int xxx[10]; 

int main() 

{ 

struct xxx { 
int a; 

}; 

printf("%d\n", sizeof(xxx)); 
return 0; 

} 

When compiled as C code, it will typically print a value like 20 or 40, whereas when 
treated as C++, the output value will likely be 2 or 4. Why is this? In C++, the intro¬ 
duction of the local struct declaration hides the global xxx, and the program is simply 
taking the size of a struct which has a single integer member in it. In C, sizeof (xxx) 
refers to the global array, and a tag like xxx doesn’t automatically refer to a struct. If we 
said sizeof (struct xxx) , then we would be able to refer to the local struct declara¬ 
tion. 

Next month: memory allocation. 
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A 

by Philippe Kaplan 

Philippe has worked for 
Dyade, a French applied 
research center, since he 
received his PhD in 1992. He 
specializes in software tools, 
and is now working on a 
graphic toolkit written in 
pure Java. 


<Philippe.Kaplan@sophia.inria.fr> 


A new language like Java means new features, new programming techniques, 
and ... a brand new generation of bugs. Articles about Java are now common 
and help to take advantage of the powerful features of the language. However, I 
have seen few articles that help debugging in this language, as if the debug 
techniques remain the same across the different programming languages. 

Believe me, this is wrong. The usual debug techniques are still valid (actually, it is hard 
to break developer habits in this area) but new techniques are available to tackle new 
kind of problems. We can improve our efficiency in debugging by taking advantage of 
Java features. 

Debugging with Objects 

Non-object-oriented programs are structured sets of data and instructions. These are 
quite straightforward to debug if you know roughly where the bug is located. Just set 
breakpoints in the guilty area and run within the debugger. When the program hits the 
breakpoint, it stops, and the context can be studied to understand and discover the bug. 

Things are different in object-oriented languages like Java. Breakpoints are still set on 
instructions; however, instructions belong to object instances. So breakpoints stop 
within all instances, and even if we know within which instance the bug is located, 
there is no way to track down only this instance. For example, assume we create an 
instance for each dynamic point of a moving graph and there is a bug in some of the 
points leading to an unexpected peak in the graph display. We know which ones among 
hundreds of points are faulty, but not how to trace only them and then detect when 
they go out of bounds. 

Threads make things worse. The developer is misled by the source code, which appears 
basically single-threaded. The developer sees one line of the program, but threads are 
actually running simultaneously at different points of the same program. The puzzle is 
real: it is difficult to visualize several threads running at different places and on differ¬ 
ent instances of the same class. Breakpoints are hit, but by which instance, within 
which thread? 

Lets forget about high-level debuggers, because today they are still far from being pow¬ 
erful enough to tackle our problem. How can we debug a threaded object with only 
println statements in the source code ? Putting println in the class definition comes to 
mind, but is not enough. It will trace the method called by all instances, and we want to 
trace only a particular instance. 

Java documentation reveals a heavier hammer, namely, Runtime. traceMethodCall (), 
which prints a line for each method call of all objects in all threads. The next section 
discusses this tracing method. However, this is still maladapted for our purposes. 

The solution appears in Java 1.1, with the inner classes. When the faulty instance is cre¬ 
ated, we override on the fly the method to be traced so it prints a message. For exam¬ 
ple, given the class Test where the method monitor has to be traced only on the 
instance objl: 

public class Test { 
public Test(int x) { 


} 
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public synchronized void monitor(String label) { 

} 

} 

// (somewhere else, in the program) 

Test objl = new Test(l); // I'm sure there is a bug in this object 
Test obj2 = new Test(2); 

Test obj3 = new Test(3); 

We subclass on the fly the suspected instance and override the method to be traced. 

The obj 1 creation becomes: 

Test objl = new Test(l) { 

public synchronized void monitor(String label) { 

// print a trace 

System.err.printIn("debug: <" + Thread.currentThread().getName() 

+ "> is calling " + this + " .monitor (" + label + ")"); 

// call the real method 
super.monitor(label); 

} 

}; 

During execution, each time the method is called on the specified object, a message line 
with the calling thread name, the object, the method name, and its argument are print¬ 
ed out synchronously, e.g.: 

debug: <main> is calling Test$l@80fOdfd.monitor(foo) 

Only the suspect instance is traced, and this object still behaves exactly as it did (the 
trace side effect excepted). The synchronized modifier ensures that the lock is acquired 
before printing the trace, so no other thread may interleave between the trace printing 
and the call of the method. Therefore, the message is indeed printed at the right time 
by the right thread. 

Without the synchronized modifier, no assumption can be made about the calling 
thread. Obviously, it doesn’t matter when the bug doesn’t deal with threads. 

If the debugger is required, just put a breakpoint at the method of the inner class. The 
anonymous inner class (AIC) name is automatically generated by appending $n behind 
the original class name, where n is the number of the AIC in this class (e.g., Test$l). 
Here is an example of a session under the debugger: 

$ jdb Test 
Initializing jdb... 

0x40786388:class(Test) 

> stop in Test$l.monitor 
Breakpoint set in Test$l.monitor 

> run 
run Test 
running ... 
main[1] 

Breakpoint hit: Test$l.monitor (Test$l:6) 
main[l] 

The debugger is stopped before the call super .monitor (label). 


The Java debugger (jdb) is 
so well integrated it allows 
remote debugging of Java 
applications in a separate 
thread. This is quite a new 
concept for developers 
(like me) who come from C 
and its symbolic debugger. 


Remote Tracing 

Java runs threads and is network aware. The Java debugger (jdb) is so well integrated it 
allows remote debugging of Java applications in a separate thread. This is quite a new 
concept for developers (like me) who come from C and its symbolic debugger. Here is 
an example of a new debugging trick. 
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Sometimes, when everything else fails, we need the ultimate debugging tool: 
traceMethodCalls (boolean) . This function enables and disables tracing at runtime 
by toggling a debug switch of the byte code interpreter. Unfortunately, it traces all 
method calls (i.e., all objects in all threads). So the output is often too verbose to be 
really workable. 

We are going to see how to let the user toggle the trace interactively without putting 
intrusive code in the application. Using this feature exactly when needed will reduce the 
volume of information produced. 

The principle is quite simple. Because the trace switch affects all the environment, it 
can be toggled from a separate thread. Indeed, the debugger thread seems the best can¬ 
didate because it works beside the application ones. So we run the Java debugger, and 
inside it we execute a standalone Java application that toggles the trace switch. 

Compile the file Trace.java that contains: 

public class Trace { 
static boolean state = false; 
public static void main (String a[]) { 
state = 'state; 

Runtime. getRuntime () . traceMethodCalls {state); 

System.out.println("method call trace n + (state?"on."off.")); 

} 

} 

This standalone application controls only the tracing device in the Java virtual 
machine. 

Start the target program, with tracing and remote debugging enabled. java_g enables 
method tracing. The -debug switch opens an external access to the application that is 
dedicated to the remote debugger jdb. 

$ j ava_g -debug myProg 

Agent password=3hszsj 

Start the remote debugger in another window. The password argument must be the one 
given by the application: 

$ jdb -host localhost -password 3hszsj 

Load the trace class (jdb window): 

> load Trace 

Proceed with the application. When you need trace, just type in jdb: 

> run Trace 

This activates the trace: all method calls are now printed out. To stop tracing, type in 
jdb again : 

> run Trace 

The trace is no longer activated, but the user is free to request the tracing again. 

Note that the Trace class does not belong to the debugged application. The debugger 
loads this class by itself and executes it in its own thread on user request. The side effect 
of the command causes application threads to be traced. The target application does 
not need any change to be traceable. Could you imagine such a miracle with gdb? 
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Remote Thread Display 

We debugged objects; we debugged method calls; now let s tackle threads. Threads are 
volatile. They appear, they disappear, they run, they wait inside or outside a monitor, 
they are suspended, and they may be numerous. 

In a single debugger window, it is hard to track a thread life and even harder to follow 
the interactions between several threads. This is why I propose a simple package to dis¬ 
play all threads and their status at regular intervals. (This package is going to be 
improved in order to provide more user control over thread execution and priority.) It 
works like a remote debugger, collecting information about threads on the target appli¬ 
cation. 

To install the package threadDebug, download threadDebug.zip 
<http://www.inria.fr/koala/phk/java/threadDebug.zip>. (The source is available from 
<http://www.inria.fr/koala/phk/java/threadDebug-src.zip>). You don’t need to unzip 
threadDebug.zip. Just set the CLASSPATH environment variable so that it also includes 
the zip file. 

The package works like the remote tracing. The application is started with the -debug 
option, and the package uses the password given to establish a connection to the appli¬ 
cation, from another window. So here is a typical session. Start the program, with 
remote debugging enabled, e.g., 

$ java -debug myProg 

Agent password=3hszsj 

Note that the program may be an applet: 

$ java -debug sun.applet.AppletViewer foo.html 

Agent password=3hszsj 

Start the remote thread displayer in another window: 

$ java threadDebug.ThreadDisplay -host localhost -password 3hszsj \ 
-refresh 2000 

The last argument is optional and sets the automatic refresh time in milliseconds. The 
default refresh time is one second. 

Several windows will pop up, one for each thread group that lists the threads of this 
group and another one for the groups. In addition, each change is printed sequentially 
on the screen. You should see something like Figure 1 on the facing page. 

The refresh buttons start a manual refresh in windows, in addition to automatic ones. 
The tool displays active and inactive threads. Threads in “running” state are highlight¬ 
ed. As the application is going on, the “thread displays” reflect the states of all the 
threads involved in the application. This tool may help locate a bug by pointing out the 
threads that run the bug. It may also be useful to detect deadlocks and starvation. 

Note also that on UNIX systems, the ctrl-backslash key (i.e., signal 3) prints a snapshot 
of all threads on stdout. The listing is more complete but less readable than the 
threadDisplay tool. 

This tool, like the previous one, does not require any change in the target application to 
be enabled. 


In a single debugger 
window, it is hard to track 
a thread life and even 
harder to follow the 
interactions between 
several threads. This is 
why I propose a simple 
package to display all 
threads and their status at 
regular intervals. 
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Figure 1: A thread debug display snapshot 
Conclusion 

Java, as a new multipurpose language, incorporates many hi-tech features. The object 
model together with the multithreading introduces a powerful new way of program¬ 
ming, but also a new class of bugs dealing with concurrent access to shared resources. 

Fortunately, Java designers, aware of the importance of good debugging tools, have set 
specialized entry points into the language and the virtual machine to ease debugging. 
Actually, the official debugger, jdb, is only a user interface to the standard Java debug 
library. 

With the ability to access debug functionalities from the language and the flexibility of 
an object-oriented model, we can create our own debug tools. These tools help to 
investigate particular situations, like we did here for objects and threads. 
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the webmaster: 


the virtual poet 

Email from CGI Scripts 

This time I want to show you the basics of creating an area on your site that 
sends email based on the information entered by a user. For my example, I'm 
going to show you the steps involved in creating the Virtual Poet. 

The concept is simple: the visitor to the site will enter his or her name, email address, 
and the name and email address of the recipient. Having specified that, the visitor will 
enter a poem, which will be mailed directly to the recipient. Of course, this is just a 
skeleton; otherwise you’ll be asking why you wouldn’t just enter the poem directly in an 
email message. But roll with me, eh? 
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Entering the Poem 

Let’s start with the entry screen-index.html- which looks like this: 

<FORM ACTION=send-poem.cgi METHOD=post> 

Your name: 

<INPUT TYPE=text NAME=yourname SIZE=50> 

<P> 

Your email address: 

<INPUT TYPE=text NAME=youremail SIZE=40> 

<P> 

Recipient name: 

<INPUT TYPE=text NAME= theimame SIZE=50> 

<P> 

Recipient email address: 

<INPUT TYPE=text NAME=theiremail SIZE=40> 

<P> 

Type in your poem here: 

<TEXTAREA NAME=poem ROWS=7 COLS=60> 

</TEXTAREA> 

<P> 

<INPUT TYPE=submit VALUE="send your poem"> 

</FORM> 

It’s a basic input form with five fields; the name and email address 
of the sender, the name and email address of the recipient, and the 
poem. If there’s anything interesting to note about this, it’s that I 
don't have a name= area on the final submit button, which means 
that the button value won’t be sent to the receiving script 
(send-poem.cgi, as specified in the ACTION clause of the FORM). 

Receiving the Poetry 

So far, the CGI scripts we’ve written have received information via 
a METHOD=get, but that’s not going to work with this particular 
scenario because we might receive more data than can be included 
on a URL line. In any case, it’s more elegant. 

To receive the information, we need to read it off the data stream. 
To do that, I’ll utilize one of a set of useful C routines I’ve previ¬ 
ously written and saved as cgi-utils.c (You can download a 
copy and read it yourself, if you’re curious.) 


Tfe Virtual M 

Who You Arc: 

Your name: | 

Your email address: | 

To Whom You Type Your Missive: 

Recipient name: ^ 

I 

Recipient email address: 

Type In your poem here: 


[ send your poem ) 
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There are some additional 
parts to the puzzle, of 
course, things that you 
need to get a full C 
program to work, but the 
gist of it has been 
presented here. 


The basic strategy for using the CGI utilities library is to use the routine 
get_cgi_environment (), which returns the data stream exactly as transmitted. A typ¬ 
ical value might look like: 

youmame=Dave&youremail=taylor@ intuitive. com& 
theirname=Dave2 &theiremai1=taylor@netcom.com& 
poem=roses+are+red+etc. 

The information is packed for transmission. That’s where the second routine comes in 
handy: cleanup () unpacks all the special encodings and lets you use the valueof () 
routine to extract specific values to the named variables. So you could easily have a 
simple line of C like: 

printf ("youmame = %s\n" , valueof ("youmame", cgienv)) ; 

Those three routines-get_cgi_environment (), cleanup (), and valueof () -are the 
heart of the cgi-utils library. Armed with them, we can get on to the actual program. 


Reading the Environment 

Here’s the beginning of the actual send-poem.c program: 

original_env = get_cgi_environment(); 
environment = cleanup(original_env); 

Then we save all the variables into their own space for easier reference: 

strcpy (youmame, valueof ("youmame", environment)) ; 
strcpy(youremail, valueof("youremail", environment)); 
strcpy (theimame, valueof (" theimame", environment) ) ; 
strcpy(theiremail, valueof("theiremail", environment)); 
strcpy(poem, valueof("poem", environment)); 

That’s the hard part. It’s all an easy progression from here, much of which is codified in 
the routine send_notification(): 


send_notification(yname, yemail, tname, temail, poem) 
char *yname, *yemail, * tname, * temail, *poem; 

{ 

FILE *pd; 

char command[SLEN]; 


sprintf(command, "/usr/sbin/sendmail -oi %s", temail); 

if ( (pd = popen (command, "w") ) == NULL) { 
printf("Couldn't open pipe '%s # \n", command); 
exit(0); 

} 


fprintf (pd, 
fprintf (pd, 
fprintf (pd, 
fprintf (pd. 


"Reply-To: %s (%s)\n", yemail, yname); 

"To: %s (%s)\n", temail, tname); 

"Subject: A Virtual Poem from %s\n", yname); 
"\n"); 


fprintf (pd, "%s has a poem for you:\n\n", yname); 
fprintf(pd, "%s\n\n", poem); 


fprintf(pd, 


" \n\nThis poem brought to you by The Virtual 
PoetAn"); 


pclose(pd) ; 

} 
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There are some additional parts to the puzzle, of course, things that you need to get a 
full C program to work, but the gist of it has been presented here. With all this plugged 
in, the Virtual Poet site is up and ready to try. 

You can visit <http://www.intuitive.com/CGI/poems/> for yourself and see what it looks like. 

Expanding the Site 

What would really make this cool, of course, would be to have the poem actually saved 
on the server and a “key” mailed to the recipient, who would then go to a specific spot 
on the site, enter the key, and receive a Web page that offers the poem in an attractive 
format. A number of virtual florists and electronic greeting card sites that do just this. 

It wouldn’t be too hard: either you would create the Web page and save it directly when 
the user enters their poem, or save an intermediate data set, then parse and create the 
page on the fly. A little help from cron to expire files as they get more than a certain 
age, and you’d be ready to compete with some very expensive, carefully designed sites. 


CompUSA* is looking for motivated 
professionals to join our team and be part 
of the nation’s leading computer retailer. 

We have the following positions open at 
our corporate offices in Dallas, TX: 

DATABASE ADMINISTRATORS - Mid to senior 

level Oracle and/or Ingres, Informix, Progress data¬ 
base administrators with AIX administrator skills. 

Team player with interpersonal skills to communicate 
effectively with all levels of management. CODE: DA 

UNIX SYSTEM ADMINISTRATORS Mid to 

senior level UNIX System administrators. Solid prob¬ 
lem solving skills with clear understanding of local and 
wide area network topologies, software functions and 
program scripting a must. Oracle and or Progress 
database administration and support experience. 

UNIX administration background (AIX on IBM 
RS6000). CODE: USA 

To apply, please forward resume with salary requirements to 
CompUSA, Attn. (Use appropriate code), 14951 N. Dallas 
Pkwy., Dallas, Tx 75240; FAX (972) 982-4942. 

Please refer to our web site for additional 
employment opportunities www.compusa.com 

COMPUSA 

THE COMPUTER SUPERSTORE ® 
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The following Reports are 
published in this column: 


The Open Group Distributed System 
Manaaement 



Nick Stoughton welcomes dialogue 
between this column and you, the read¬ 
ers. Please send any comments you might 
have to: <nick@usenix.org> 


standards 

reports 


An Update on 
Standards Relevant to 
USENIX Members 


by Nicholas M. 
Stoughton 

USENIX Standards Liaison 


J 



<nick@usenix.org> 


Quo Vadis POSIX? 

In July, a senior vice president from 
Hewlett-Packard, Larry Dwyer, was invit¬ 
ed to make a presentation to the Sponsor 
Executive Committee (SEC) of the 
Portable Applications Standards 
Committee (PASC) on why they should 
stop producing POSIX standards. 
Essentially his argument was “POSIX has 
been a good thing in the past, but our 
customers are idiots who don't under¬ 
stand that POSIX is not one standard but 
many. As a result, the term “POSIX con¬ 
formant system” has now lost any real 
meaning, and its too expensive for us to 
keep up” 

Now it may not sound like too good a 
strategy to go to your customers and tell 
them that they are idiots. It may not 
sound like a good strategy to go to a 
bunch of dedicated standards producers 
and tell them they are wasting their time. 
But we are people not easily offended, 
and we actually listened to him. We are 
even acting on some of his comments. 
The SEC came up with eight items for 
further discussion: 

1. Demonstrate a clear commitment to 
backward compatibility, whenever pos¬ 
sible, for POSIX. 1 and POSIX.2. 

2. Change the structure of POSIX. 1 and 
POSIX.2 and their amendments so that 


options in new amendments do not 
require vendors to revise their systems 
that do not claim to support those 
options. 

3. Based on an architectural perspective, 
develop a new set of POSIX named 
“profiles.” Develop a guideline, a 
touchstone, to determine what subjects 
are and are not “POSIX.” 

4 Define a limit to amendments to 
POSIX. 1 and POSIX.2. Raise the hur¬ 
dle to add new things. 

5 Collaborate with The Open Group for 
marketing, branding and conformance 
testing, while retaining open participa¬ 
tion. 

6 Work with IEEE to provide for corpo¬ 
rate representation in the IEEE ballot 
process, independent of individual 
member balloting rights. 

7 Identify and fix bugs in process, e.g., 
stale balloting groups and how to 
freshen them in timely fashion. 

8 Provide additional mechanisms for 
soliciting broader input on new Project 
Requests (e.g., 3 month delay for com¬ 
munity input, etc). 

Most of these points have now been dis¬ 
cussed and actioned. In some cases, the 
discussion demonstrated that we rejected 
the idea; for example, there will be no 
limit imposed on amendments to 
POSIX. 1 or POSIX.2. New features will 
generally be made optional, with minimal 
effort required from a vendor that does 
not want to support that option; all it has 
to do is to redefine the value of 
POSix_versION and it conforms to the 
new version of the standard! In general, 
we do not expect vendors to ignore all 
new optional features, but the let out is 
there. 

Working to try to improve the process is 
like trying to push gravel up a steep hill. 
You think you are making headway, till 
you realize that most of the stones have 
slipped back down the hill again! 
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Corporate representation, for example, is 
such an anathema to so many IEEE staff 
that many of us doubt it will ever hap¬ 
pen. But we continue to lobby for it. In 
reality, very few of the “individuals” who 
are working on POSIX standards really 
are working independently; they are all 
on company time and pay. When they 
change jobs, they often stop coming, or 
stop responding to ballots. Individual 
membership should never be prevented, 
but it seems ridiculous that people who 
do not want to be involved cannot hand 
over responsibilities to someone who 
does. Actually, that is one area where we 
appear to be winning; individuals can 
now opt out of a ballot group for the first 
time. And new members can join as 
observers but without the ability to cast a 
binding vote. Of course, the ballot review 
committee is unlikely to ignore input 
from someone who is able and willing to 
express an opinion, even if that opinion 
is not binding. 

Part of the Dwyer argument was that we 
in PASC are producing more and more 
specialized options that few people want. 
But in the same breath, he complains that 
customers are demanding these options. 
If customers want them, then they'll pay 
for them to be implemented. 

The “Dwyer Approach” has been an inter¬ 
esting exercise, but by far the best 
method to make sure that the standards 
we produce are useful and implementable 
is to join the working group, join the bal¬ 
lot group, and steer the standard in the 
right direction, rather than attacking the 
integrity of the individuals currently 
involved. 

Revising POSIX. 1 Classic 

The POSIX. 1 standard was first published 
in 1986 as a trial use standard, then again 
in 1988 as a full use standard. Sub¬ 
sequently, it was revised and republished 
in 1990 as an international standard (ISO 
9945-1:1990). All standards in IEEE and 
in ISO are subject to a five-year review, at 
which point they must be reaffirmed, 


revised or withdrawn. We reaffirmed 
POSIX. 1 in 1995 with a minimum of 
fuss. However, the time is fast approach¬ 
ing for the second of these review points, 
and we know this time we do need to 
revise the standard. A revision will have a 
number of effects; the entire document, 
including all the published amendments, 
is open for review. The result will not be 
one standard and a bunch of amend¬ 
ments (as it is now), but a single unified 
standard to which further amendments 
can be made. 

The amendments that are expected to be 
finished by 2000, and therefore included 
in the new revised standard, are 
POSIX.la (system API extensions), lb 
(realtime), lc (threads), Id (advanced 
realtime), lg (protocol independent 
interfaces, sockets etc), lh (services for 
reliable, available and serviceable sys¬ 
tems), li (realtime corrigenda), lm 
(checkpoint/restart), and In (corrigen¬ 
da). Now the astute among you may have 
noticed that less than half of this list is as 
yet actually published! How can we revise 
something that is only a few months old? 
Well, the answer is that with good man¬ 
agement, we won't actually touch those 
parts; they will be written ready to go 
into the new standard. But before the 
revision, they are standards that amend 
POSIX. 1; after it, they will simply be part 
of POSIX. 1. 

The Project Authorization Request (PAR) 
for this revision is going through the 
approval process right now, and limits 
the scope of the revision to just the func¬ 
tionality in the original document and 
the amendments; in other words, we can’t 
go pushing new stuff into this revision. 
We can try to make sure that things work 
coherently throughout the standard; for 
example, error handling and option han¬ 
dling differ from amendment to amend¬ 
ment currently, and we could straighten 
this out. 

The other big issue with the revision is: 
who is going to do it? If nobody comes 


forward willing to volunteer the time and 
effort, then this revision may never hap¬ 
pen. It has a very finite time span. It must 
be finished by the end of 2000, or the old 
standard must be reaffirmed. It is unlike¬ 
ly that we would be allowed to reaffirm 
again, since there are now too many 
amendments. No volunteers, and 
POSIX. 1 could just be withdrawn. It is 
possible that The Open Group might vol¬ 
unteer to assist in this, since they recog¬ 
nize the value of the standard. But even if 
it does, we need real users of the standard 
involved as well as the vendors. Please let 
me know if you can help! 

The Open Group Distributed System 
Management 

Nick Stoughton <nick@usenix.org> reports on 
the September 1997 meeting in Boston , 

MA. 

The IT DialTone, as I have reported pre¬ 
viously, is the new Open Group initiative 
to cause the creation of a viable global 
information infrastructure that is ubiqui¬ 
tous, trusted, reliable, and as easy to use 
as the telephone. Work is now under way 
on phase one of this project. Phase one is 
intended to be a consolidation of what 
exists, trying to bring it all together into 
the common direction toward which we 
are aiming. To this end, a taxonomy of 
management services has been produced, 
and work is under way to revise the 
X/Open Manageability Guidelines (a doc¬ 
ument presented for other working 
groups to understand where and how to 
include management interfaces in the 
work they are producing). 

Manageability is one of the key elements 
of the IT DialTone. Within the IT 
DialTone environment, management 
extends beyond the traditional confines 
of managing IT platforms and networks. 
Successful management for the IT 
DialTone must provide a comprehensive 
management capability that encompasses 
the full end-to-end viewpoint that is 
experienced by the application program¬ 
mers and users of the environment. 
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